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Foreword 


This foreword is not part of American National Standard INCITS.***:200x. 

The purpose of this standard is to provide a basis for the coordination of SCSI standards development and to 
define requirements, common to all SCSI technologies and implementations, that are essential for compatibility 
with host SCSI application software and device-resident firmware across all SCSI transport protocols. These 
requirements are defined through a reference model that specifies the behavior and abstract structure that is 
generic to all SCSI I/O system implementations. 

With any technical document there may arise questions of interpretation as new products are implemented. INCITS 
has established procedures to issue technical opinions concerning the standards developed by INCITS. These 
procedures may result in SCSI Technical Information Bulletins being published by INCITS. 

These Bulletins, while reflecting the opinion of the Technical Committee that developed the standard, are intended 
solely as supplementary information to other users of the standard. This standard, ANSI INCITS.***:200x, as 
approved through the publication and voting procedures of the American National Standards Institute, is not altered 
by these bulletins. Any subsequent revision to this standard may or may not reflect the contents of these Technical 
Information Bulletins. 


Current INCITS practice is to make Technical Information Bulletins available through: 


INCITS Online Store 
managed by Techstreet 
1327 Jones Drive 
Ann Arbor, Ml 48105 

or 

Global Engineering 
15 Inverness Way East 
Englewood, CO 80112-5704 


http://www.techstreet.com/INCITS.html 
Telephone: 1-734-302-7801 or 
1-800-699-9277 
Facsimile: 1-734-302-7811 


http://global.ihs.com/ 
Telephone: 1-303-792-2181 or 
1-800-854-7179 
Facsimile: 1-303-792-2192 


Requests for interpretation, suggestions for improvement and addenda, or defect reports are welcome. They 
should be sent to the INCITS Secretariat, National Committee for Information Technology Standards, Information 
Technology Institute, 1250 Eye Street, NW, Suite 200, Washington, DC 20005- 3922. 

This standard was processed and approved for submittal to ANSI by the InterNational Committee for Information 
Technology Standards (INCITS). Committee approval of the standard does not necessarily imply that all committee 
members voted for approval. At the time of it approved this standard, INCITS had the following members: 

cclnsert INCITS member list» 
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Introduction 

The SCSI Architecture Model - 3 (SAM-3) standard is divided into the following clauses and annexes: 

Clause 1 is the scope. 

Clause 2 enumerates the normative references that apply to this standard. 

Clause 3 describes the definitions, symbols, and abbreviations used in this standard. 

Clause 4 describes the overall SCSI architectural model. 

Clause 5 describes the SCSI command model element of the SCSI architecture. 

Clause 6 describes the events that may be detected by a SCSI device. 

Clause 7 describes the task management functions common to SCSI devices. 

Clause 8 describes the task set management capabilities common to SCSI devices. 

Annex A summarizes the identifier and name definitions of the SCSI transport protocols. 

Annex B identifies differences between the terminology used in this standard and previous versions of this 
standard. 
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American National Standard INCITS.***:200x 

American National Standard 
for Information Technology - 

SCSI Architecture Model - 3 (SAM-3) 

1 Scope 

1.1 Introduction 

The set of SCSI (Small Computer System Interface) standards consists of this standard and the SCSI implemen¬ 
tation standards described in 1.3. This standard defines a reference model that specifies common behaviors for 
SCSI devices, and an abstract structure that is generic to all SCSI I/O system implementations. 

The set of SCSI standards specifies the interfaces, functions, and operations necessary to ensure interoperability 
between conforming SCSI implementations. This standard is a functional description. Conforming implementations 
may employ any design technique that does not violate interoperability. 

The following architecture model concepts from previous versions of this standard are made obsolete by this 
standard: 

a) Support for the SPI-5 SCSI transport protocol (except for informational listings in Annex A); 

b) Contingent Allegiance; 

c) The TARGET RESET task management function; and 

d) Untagged tasks. 
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1.2 Requirements precedence 

This standard defines generic requirements that pertain to SCSI implementation standards and implementation 
requirements. An implementation requirement specifies behavior in terms of measurable or observable parameters 
that apply to an implementation. Examples of implementation requirements defined in this document are the status 
values to be returned upon command completion and the service responses to be returned upon task 
management function completion. 

Generic requirements are transformed to implementation requirements by an implementation standard. An 
example of a generic requirement is the hard reset behavior specified in 6.3.2. 



Figure 1 — Requirements precedence 


As shown in figure 1, all SCSI implementation standards shall reflect the generic requirements defined herein. In 
addition, an implementation claiming SCSI compliance shall conform to the applicable implementation require¬ 
ments defined in this standard and the appropriate SCSI implementation standards. In the event of a conflict 
between this document and other SCSI standards under the jurisdiction of technical committee T10, the require¬ 
ments of this standard shall apply. 
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1.3 SCSI standards family 

Figure 2 shows the relationship of this standard to the other standards and related projects in the SCSI family 
standards as of the publication of this standard. 



Figure 2 — SCSI document structure 


The roadmap in figure 2 is intended to show the general applicability of the documents to one another. Figure 2 is 
not intended to imply a relationship such as a hierarchy, protocol stack, or system architecture. 

The functional areas identified in figure 2 characterize the scope of standards within a group as follows: 

Architecture Model: Defines the SCSI systems model, the functional partitioning of the SCSI standard set and 
requirements applicable to all SCSI implementations and implementation standards. 

Device-Type Specific Command Sets: Implementation standards that define specific device types including a 
device model for each device type. These standards specify the required commands and behavior that is specific to 
a given device type and prescribe the requirements to be followed by a SCSI initiator device when sending 
commands to a SCSI target device having the specific device type. The commands and behaviors for a specific 
device type may include by reference commands and behaviors that are shared by all SCSI devices. 

Shared Command Set: An implementation standard that defines a model for all SCSI device types. This standard 
specifies the required commands and behavior that is common to all SCSI devices, regardless of device type, and 
prescribes the requirements to be followed by a SCSI initiator device when sending commands to any SCSI target 
device. 

SCSI Transport Protocols: Implementation standards that define the requirements for exchanging information so 
that different SCSI devices are capable of communicating. 

Interconnects: Implementation standards that define the communications mechanism employed by the SCSI 
transport protocols. These standards may describe the electrical and signaling requirements essential for SCSI 
devices to interoperate over a given interconnect. Interconnect standards may allow the interconnection of devices 
other than SCSI devices in ways that are outside the scope of this standard. 

At the time this standard was generated, examples of the SCSI general structure included: 
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Interconnects: 

Fibre Channel Arbitrated Loop - 2 


Fibre Channel Physical Interfaces 

Fibre Channel Physical Interfaces - 2 
Fibre Channel Framing and Signaling Interface 

High Performance Serial Bus 
High Performance Serial Bus 
(supplement to ANSI/IEEE 1394-1995) 

SCSI Parallel Interface - 2 

SCSI Parallel Interface - 3 

SCSI Parallel Interface - 4 

SCSI Parallel Interface - 5 

Serial Storage Architecture Physical Layer 1 
Serial Storage Architecture Physical Layer 2 
Serial Attached SCSI 

Serial Attached SCSI -1.1 


SCSI Transport Protocols: 

Automation/Drive Interface - Transport Protocol 

Serial Storage Architecture Transport Layer 1 
Serial Storage Architecture Transport Layer 2 
SCSI-3 Fibre Channel Protocol 

SCSI Fibre Channel Protocol - 2 

SCSI Fibre Channel Protocol - 3 

Serial Bus Protocol - 2 

Serial Bus Protocol - 3 

Serial Storage Architecture SCSI-3 Protocol 
SCSI RDMA Protocol 

SCSI RDMA Protocol - 2 


Shared Command Sets: 

SCSI-3 Primary Commands 
SCSI Primary Commands - 2 

SCSI Primary Commands - 3 


FC-AL-2 

[ISO/I EC 14165-122] 

[ANSI NCITS.332-1999] 
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FC-PI 
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FC-PI-2 
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FCP 

[ISO/IEC 14776-221] 

[ANSI X3.269-1996] 

FCP-2 

[ISO/IEC 14776-222] 

[ANSI NCITS.350-2003] 

FCP-3 

[ISO/IEC 14776-223] 
[T10/1560-D] 

SBP-2 

[ISO/IEC 14776-232] 

[ANSI NCITS.325-1999] 

SBP-3 

[ISO/IEC 14776-233] 
[T10/1467-D] 

SSA-S3P 

[ANSI NCITS.309-1998] 

SRP 

[ISO/IEC 14776-241] 
[T10/1415-D] 

SRP-2 

[ISO/IEC 14776-242] 
[T10/1524-D] 

SPC 

[ANSI X3.301-1997] 

SPC-2 

[ISO/IEC 14776-452] 

[ANSI NCITS.351-2001] 

SPC-3 

[ISO/IEC 14776-453] 
[T10/1416-D] 
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Device-Type Specific Command Sets: 


SCSI-3 Block Commands 

SBC 

[ISO/I EC 14776-321] 
[ANSI NCITS.306-1998] 

SCSI Block Commands - 2 

SBC-2 

[ISO/I EC 14776-322] 
[T10/1417-D] 

SCSI-3 Stream Commands 

SSC 

[ISO/IEC 14776-331] 
[ANSI NCITS.335-2000] 

SCSI Stream Commands - 2 

SSC-2 

[ISO/IEC 14776-332] 
[ANSI INCITS.380-2003] 

SCSI Stream Commands - 3 

SSC-3 

[ISO/IEC 14776-333] 
[T10/1611-D] 

SCSI-3 Medium Changer Commands 

SMC 

[ISO/IEC 14776-351] 
[ANSI NCITS.314-1998] 

SCSI Media Changer Commands - 2 

SMC-2 

[ISO/IEC 14776-352] 
[T10/1383-D] 

SCSI-3 Multimedia Command Set 

MMC 

[ANSI X3.304-1997] 

SCSI Multimedia Command Set - 2 

MMC-2 

[ISO/IEC 14776-362] 
[ANSI NCITS.333-2000] 

SCSI Multimedia Command Set - 3 

MMC-3 

[ISO/IEC 14776-363] 
[ANSI INCITS.360-2002] 

SCSI Multimedia Command Set - 4 

MMC-4 

[ISO/IEC 14776-364] 
[T10/1545-D] 

SCSI Multimedia Command Set - 5 

MMC-5 

[ISO/IEC 14776-365] 
[T10/1675-D] 

SCSI Controller Commands - 2 

SCC-2 

[ISO/IEC 14776-342] 
[ANSI NCITS.318-1998] 

SCSI Reduced Block Commands 

RBC 

[ISO/IEC 14776-326] 
[ANSI NCITS.330-2000] 

SCSI-3 Enclosure Services Commands 

SES 

[ISO/IEC 14776-371] 
[ANSI NCITS.305-1998] 

SCSI Enclosure Services Commands - 2 

SES-2 

[ISO/IEC 14776-372] 
[T10/1559-D] 

SCSI Specification for Optical Card Reader/Writer 

OCRW 

[ISO/IEC 14776-381] 

Object-based Storage Device Commands 

OSD 

[ISO/IEC 14776-391] 
[T10/1355-D] 

SCSI Management Server Commands 

MSC 

[ISO/IEC 14776-511] 
[T10/1528-D] 

Automation/Drive Interface - Commands 

ADC 

[ISO/IEC 14776-356] 
[T10/1558-D] 

Architecture Model: 

SCSI-3 Architecture Model 

SAM 

[ISO/IEC 14776-411] 
[ANSI X3.270-1996] 

SCSI Architecture Model - 2 

SAM-2 

[ISO/IEC 14776-412] 
[ANSI INCITS.366-2003] 

SCSI Architecture Model - 3 

SAM-3 

[ISO/IEC 14776-413] 
[T10/1561-D] 

SCSI Architecture Model - 4 

SAM-4 

[ISO/IEC 14776-414] 
[T10/1683-D] 


The term SCSI is used to refer to the family of standards described in this subclause. 
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2 Normative references 

2.1 Normative references 

The following standards contain provisions that, by reference in the text, constitute provisions of this standard. At 
the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agree¬ 
ments based on this standard are encouraged to investigate the possibility of applying the most recent editions of 
the standards listed below. 

Copies of the following documents may be obtained from ANSI: approved ANSI standards, approved and draft 
international and regional standards (ISO, IEC, CEN/CENELEC, ITUT), and approved and draft foreign standards 
(including BSI, JIS, and DIN). For further information, contact ANSI Customer Service Department at 
212-642-4900 (phone), 212-302-1286 (fax) or via the World Wide Web at http://www.ansi.org. 


2.2 Approved references 

I SO/I EC 14776-452, SCSI Primary Commands - 2 (SPC-2) [ANSI NCITS.351-2001] 

ISO/IEC 60027-2-am2 (1999-01), Letter symbols to be used in electrical technology - Part 2: Telecommunications 
and electronics (Amendment 2) 


2.3 References under development 

At the time of publication, the following referenced standards were still under development. For information on the 
current status of the document, or regarding availability, contact the relevant standards body or other organization 
as indicated. 

ISO/IEC 14776-453, SCSI Primary Commands - 3 (SPC-3) [T10/1416-D] 

ISO/IEC 14776-322, SCSI Block Commands - 2 (SBC-2) [T10/1417-D] 
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3 Definitions, symbols, abbreviations, and conventions 

3.1 Definitions 

3.1.1 ACA command: A command performed by a task with the ACA attribute (see 3.1.5, 4.11, and 8.6.5). 

3.1.2 additional sense code: A combination of the additional sense code and additional sense code qualifier 
fields in the sense data (see 3.1.108 and SPC-3). 

3.1.3 application client: An object that is the source of commands and task management function requests. 

3.1.4 argument: A datum provided as input to or output from a procedure call (see 3.1.76). 

3.1.5 auto contingent allegiance (ACA): The task set condition established following the return of a CHECK 
CONDITION status when the naca bit is set to one in the control byte. See 5.9.2. 

3.1.6 background operation: An operation started by a command that continues processing after the task 
containing the command is no longer in the task set. See 5.5. 

3.1.7 basic task management model: The task management model in which only one task attribute (see 8.6) is 
supported and the task management features that the application client may select are limited. See 8.3.3. 

3.1.8 blocked task state: When in this state a task is prevented from completing due to an ACA condition. 

3.1.9 blocking boundary: A task set boundary denoting a set of conditions that inhibit tasks outside the boundary 
from entering the enabled task state. 

3.1.10 byte: An 8-bit construct. 

3.1.11 client-server: A relationship established between a pair of distributed entities where one (the client) 
requests the other (the server) to perform some operation or unit of work on the client's behalf. 

3.1.12 client: An entity that requests a service from a server. This standard defines one client, the application 
client. 

3.1.13 code value: A defined numeric value, possibly a member of a series of defined numeric values, repre¬ 
senting an identified and described instance or condition. Code values are defined to be used in a specific field 
(see 3.1.37), in a procedure call input argument (see 3.6.2), in a procedure call output argument, or in a procedure 
call result. 

3.1.14 command: A request describing a unit of work to be performed by a device server. 

3.1.15 command descriptor block (CDB): A structure used to communicate a command from an application 
client to a device server. A CDB may have a fixed length of 6 bytes, 10 bytes, 12 bytes, or 16 bytes, or a variable 
length of between 12 and 260 bytes. See 5.2 and SPC-3. 

3.1.16 command standard: A SCSI standard that defines the model, commands, and parameter data for a 
device type (e.g., SPC-3, SBC-2, SSC-2, SMC-2, MMC-4, or SES-2). See clause 1. 

3.1.17 completed command: A command that has ended by returning a status and service response of task 

COMPLETE or LINKED COMMAND COMPLETE. 


dpANS SCSI Architecture Model - 3 (SAM-3) 



21 September 2004 


T10/1561-D revision 14 


3.1.18 completed task: A task that has ended by returning a status and service response of task complete. 
The actual events comprising the task complete response are SCSI transport protocol specific. 

3.1.19 confirmation: A response returned to an application client or device server that signals the completion of a 
service request. 

3.1.20 confirmed SCSI transport protocol service: A service available at the SCSI transport protocol service 
interface that includes a confirmation of completion. See 4.15. 

3.1.21 current task: A task that has a data transfer SCSI transport protocol service request in progress (see 
5.4.3) or is in the process of sending command status. Each SCSI transport protocol standard may define the SCSI 
transport protocol specific conditions under which a task is considered a current task. 

3.1.22 deferred error: An error generated by a background operation (see 3.1.6). 

3.1.23 dependent logical unit: A logical unit that is addressed via some other logical unit(s) in a hierarchical 

logical unit structure (see 3.1.41), also a logical unit that is at a higher numbered level in the hierarchy than the 

referenced logical unit (see 4.14). 

3.1.24 device identifier: A term used by previous versions of this standard (see Annex B). 

3.1.25 device model: The description of a type of SCSI target device (e.g., block, stream). 

3.1.26 device server: An object within a logical unit that processes SCSI tasks according to the requirements for 
task management described in clause 8. 

3.1.27 device service request: A request submitted by an application client conveying a command to a device 
server. 

3.1.28 device service response: The response returned to an application client by a device server on completion 
of a command. 

3.1.29 domain: An I/O system consisting of a set of SCSI devices and a service delivery subsystem, where the 
SCSI devices interact with one another by means of the service delivery subsystem. 

3.1.30 dormant task state: When in this state a task is prevented from entering the enabled task state (see 
3.1.31) due to the presence of certain other tasks in the task set. 

3.1.31 enabled task state: When in this state a task may complete at any time or is waiting to receive the next 
command in a series of linked commands. 

3.1.32 extended logical unit addressing: The logical unit addressing method used by special function logical 
units (e.g., well known logical units). See 4.9.9. 

3.1.33 faulted l_T nexus: The l_T nexus on which a CHECK CONDITION status was returned that resulted in the 
establishment of an ACA. The faulted l_T nexus condition is cleared when the ACA condition is cleared. 

3.1.34 faulted task set: A task set that contains a faulting task. The faulted task set condition is cleared when the 
ACA condition resulting from the CHECK CONDITION status is cleared. 

3.1.35 faulting command: A command that completed with a status of CHECK CONDITION that resulted in the 
establishment of an ACA. 
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3.1.36 faulting task: A task that has completed with a status of CHECK CONDITION that resulted in the estab¬ 
lishment of an ACA. 

3.1.37 field: A group of one or more contiguous bits, part of a larger structure (e.g., a CDB (see 3.1.15) or sense 
data (see 3.1.108)). 

3.1.38 full task management model: The task management model in which the simple task attribute (see 8.6.1) 
is supported and all task management features may be selected by the application client. See 8.3.2. 

3.1.39 function complete: A logical unit response indicating that a task management function has finished. The 
events comprising this response are SCSI transport protocol specific. 

3.1.40 hard reset: A condition resulting from a power on condition or a reset event in which the SCSI device 
performs the hard reset operations described in 6.3.2, SPC-3, and the appropriate command standards. 

3.1.41 hierarchical logical unit: An inverted tree structure for forming and parsing logical unit numbers (see 
3.1.64) containing up to four addressable levels (see 4.14). 

3.1.42 l_T nexus: A nexus between a SCSI initiator port and a SCSI target port. See 4.12. 

3.1.43 l_T nexus loss: A condition resulting from a hard reset condition or an l_T nexus loss event in which the 
SCSI device performs the l_T nexus loss operations described in 6.3.4, SPC-3, and the appropriate command 
standards. 

3.1.44 l_T nexus loss event: A SCSI transport protocol specific event that results in an l_T nexus loss condition 
as described in 6.3.4. 

3.1.45 l_T_L nexus: A nexus between a SCSI initiator port, a SCSI target port, and a logical unit (see 4.12). 

3.1.46 l_T_L_Q nexus: A nexus between a SCSI initiator port, a SCSI target port, a logical unit, and a task. See 
4.12. 

3.1.47 l_T_L_Q nexus transaction: The information transferred between SCSI ports in a single data structure 
with defined boundaries (e.g., an information unit). 

3.1.48 l_T_L_x nexus: Either an l_T_L nexus or an l_T_L_Q nexus. See 4.12. 

3.1.49 I/O operation: An operation defined by an unlinked command, a series of linked commands or a task 
management function. 

3.1.50 implementation specific: A requirement or feature that is defined in a SCSI standard but whose imple¬ 
mentation may be specified by the system integrator or vendor. 

3.1.51 initiator: A term used by previous versions of this standard (see Annex B). 

3.1.52 initiator device name: A SCSI device name of a SCSI initiator device. See 4.7.1. 

3.1.53 initiator identifier: A term used by previous versions of this standard (see Annex B). 

3.1.54 initiator port identifier: A value by which a SCSI initiator port is referenced within a domain. See 4.7.1. 

3.1.55 initiator port name: A SCSI port name (see 3.1.97) of a SCSI initiator port or of a SCSI target/initiator port 
when operating as a SCSI initiator port. See 4.7.1. 
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3.1.56 in transit: Information that has been delivered to the service delivery subsystem for transmission, but not 
yet received. 

3.1.57 implicit head of queue: An optional processing model for specified commands wherein the first command 
in a task may be treated as if it had been received with a head of queue task attribute. See 8.2. 

3.1.58 layer: A subdivision of the architecture constituted by SCSI initiator device and SCSI target device 
elements at the same level relative to the interconnect. 

3.1.59 linked command: One in a series of commands processed by a single task that collectively make up a 
discrete I/O operation. In such a series, each command is represented by the same l_T_L_Q nexus, and all, except 
the last, have the link bit in the CDB control byte set to one. 

3.1.60 logical unit: A SCSI target device object, containing a device server and task manager, that implements a 
device model and manages tasks to process commands sent by an application client. See 4.8. 

3.1.61 logical unit reset: A condition resulting from a hard reset condition or a logical unit reset event in which the 
logical unit performs the logical unit reset operations described in 6.3.3, SPC-3, and the appropriate command 
standards. 

3.1.62 logical unit reset event: An event that results in a logical unit reset condition as described in 6.3.3. 

3.1.63 logical unit inventory: The list of the logical unit numbers reported by a REPORT LUNS command (see 
SPC-3). 

3.1.64 logical unit number (LUN): A 64-bit or 1 6-bit identifier for a logical unit. See 4.9. 

3.1.65 name: A label of an object that is unique within a specified context and should never change (e.g., the 
terms name and world wide identifier (WWID) may be interchangeable). 

3.1.66 nexus: A relationship between two SCSI devices, and the SCSI initiator port and SCSI target port objects 
within those SCSI devices. See 4.12. 

3.1.67 non-faulted l_T nexus: An l_T nexus that is not a faulted l_T nexus (see 3.1.33). 

3.1.68 object: A container that encapsulates data types, services, or other objects that are related in some way. 

3.1 .69 peer entities: Entities within the same layer (see 3.1.58). 

3.1.70 pending command: From the point of view of the application client, the description of command between 
the time that the application client calls the Send SCSI Command SCSI transport protocol service and the time 
one of the SCSI target device responses described in 5.5 is received. 

3.1.71 port: Synonymous with SCSI port (see 3.1.95 and Annex B). 

3.1.72 power cycle: Power being removed from and later applied to a SCSI device. 

3.1.73 power on: A condition resulting from a power on event in which the SCSI device performs the power on 
operations described in 6.3.1, SPC-3, and the appropriate command standards. 

3.1.74 power on event: Power being applied to a SCSI device, resulting in a power on condition as described in 
6.3.1. 

3.1.75 procedure: An operation that is invoked through an external calling interface. 
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3.1.76 procedure call: The model used by this standard for the interfaces involving both the SAL (see 3.1.86) and 
STPL (see 3.1.102), having the appearance of a programming language function call. 

3.1.77 protocol: A specification and/or implementation of the requirements governing the content and exchange 
of information passed between distributed entities through the service delivery subsystem. 

3.1.78 queue: The arrangement of tasks within a task set (see 3.1.130), usually according to the temporal order in 
which they were created. 

3.1.79 receiver: A client or server that is the recipient of a service delivery transaction. 

3.1.80 reference model: A standard model used to specify system requirements in an implementation- 
independent manner. 

3.1.81 relative port identifier: An identifier for a SCSI port that is unique within a SCSI device. See 4.7.5. 

3.1.82 request: A transaction invoking a service. 

3.1.83 request-response transaction: An interaction between a pair of distributed, cooperating entities, 
consisting of a request for service submitted to an entity followed by a response conveying the result. 

3.1.84 reset event: A SCSI transport protocol specific event that results in a hard reset condition as described in 
6.3.2. 

3.1.85 response: A transaction conveying the result of a request. 

3.1.86 SCSI application layer (SAL): The protocols and procedures that implement or issue commands and task 
management functions by using services provided by a SCSI transport protocol layer. 

3.1.87 SCSI device: A device that contains one or more SCSI ports that are connected to a service delivery 
subsystem and supports a SCSI application protocol. 

3.1.88 SCSI device identifier: Synonymous with SCSI port identifier (see 3.1.96). 

3.1.89 SCSI device name: A name (see 3.1.65) of a SCSI device that is world wide unique within the SCSI 
transport protocol of a SCSI domain in which the SCSI device has SCSI ports (see 4.7.7). The SCSI device name 
may be made available to other SCSI devices or SCSI ports in SCSI transport protocol specific ways. 

3.1.90 SCSI event: A condition defined by this standard (e.g., logical unit reset) that is detected by SCSI device 
and that requires notification of its occurrence within the SCSI device. See clause 6. 

3.1.91 SCSI I/O system: An I/O system, consisting of two or more SCSI devices, a SCSI interconnect and a SCSI 
transport protocol that collectively interact to perform SCSI I/O operations. 

3.1.92 SCSI identifier: A term used by previous versions of this standard (see Annex B). 

3.1.93 SCSI initiator device: A SCSI device containing application clients and SCSI initiator ports that originates 
device service and task management requests to be processed by a SCSI target device and receives device 
service and task management responses from SCSI target devices. When used this term refers to SCSI initiator 
devices or SCSI target/initiator devices that are using the SCSI target/initiator port as a SCSI initiator port. 
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3.1.94 SCSI initiator port: A SCSI initiator device object that acts as the connection between application clients 
and the service delivery subsystem through which requests, indications, responses, and confirmations are routed. 
In all cases when this term is used it refers to an initiator port or a SCSI target/initiator port operating as a SCSI 
initiator port. 

3.1.95 SCSI port: A SCSI device resident object that connects the application client, device server or task 
manager to the service delivery subsystem through which requests and responses are routed. SCSI port is synon¬ 
ymous with port. A SCSI port is one of: a SCSI initiator port (see 3.1.94), a SCSI target port (see 3.1.99), or a SCSI 
target/initiator port (see 3.1.101). 

3.1.96 SCSI port identifier: A value by which a SCSI port is referenced within a domain. The SCSI port identifier 
is either an initiator port identifier (see 3.1.54) or a target port identifier (see 3.1.119). 

3.1.97 SCSI port name: A name (see 3.1.65) of a SCSI port that is world wide unique within the SCSI transport 
protocol of the SCSI domain of that SCSI port (see 4.7.8). The name may be made available to other SCSI devices 
or SCSI ports in that SCSI domain in SCSI transport protocol specific ways. 

3.1.98 SCSI target device: A SCSI device containing logical units and SCSI target ports that receives device 
service and task management requests for processing and sends device service and task management responses 
to SCSI initiator devices. When used this term refers to SCSI target devices or SCSI target/initiator devices that are 
using the SCSI target/initiator port as a SCSI target port. 

3.1.99 SCSI target port: A SCSI target device object that contains a task router and acts as the connection 
between device servers and task managers and the service delivery subsystem through which indications and 
responses are routed. When this term is used it refers to a SCSI target port or a SCSI target/initiator port operating 
as a SCSI target port. 

3.1.100 SCSI target/initiator device: A SCSI device that has all the characteristics of a SCSI target device and a 
SCSI initiator device. 

3.1.101 SCSI target/initiator port: A SCSI device resident object that has all the characteristics of a SCSI target 
port and a SCSI initiator port. 

3.1.102 SCSI transport protocol layer (STPL): The protocol and services used by a SCSI application layer to 
transport data representing a SCSI application protocol transaction. 

3.1.103 SCSI transport protocol service confirmation: A procedure call from the STPL notifying the SAL that a 
SCSI transport protocol service request has completed. 

3.1.104 SCSI transport protocol service indication: A procedure call from the STPL notifying the SAL that a 
SCSI transport protocol transaction has occurred. 

3.1.105 SCSI transport protocol service request: A procedure call to the STPL to begin a SCSI transport 
protocol service transaction. 

3.1.106 SCSI transport protocol service response: A procedure call to the STPL containing a reply from the 
SAL in response to a SCSI transport protocol service indication. 

3.1.107 sender: A client or server that originates a service delivery transaction. 

3.1.108 sense data: Data returned to an application client in the same l_T_L_Q nexus transaction (see 3.1.47) as 
a CHECK CONDITION status (see 5.9.6). Fields in the sense data are referenced by name in this standard. See 
SPC-3 for a complete sense data format definition. Sense data may also be retrieved using the REQUEST SENSE 
command (see SPC-3). 
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3.1.109 sense key: The sense key field in the sense data (see 3.1.108 and SPC-3). 

3.1.110 server: An entity that performs a service on behalf of a client. 

3.1.111 service: Any operation or function performed by a SCSI object that is invoked by other SCSI objects. 

3.1.112 service delivery failure: Any non-recoverable error causing the corruption or loss of one or more service 
delivery transactions while in transit. 

3.1.113 service delivery subsystem: That part of a SCSI I/O system that transmits service requests to a logical 
unit or SCSI target device and returns logical unit or SCSI target device responses to a SCSI initiator device. 

3.1.114 service delivery transaction: A request or response sent through the service delivery subsystem. 

3.1.115 standard INQUIRY data: Data returned to an application client as a result of an INQUIRY command with 
the evpd bit set to zero. Fields in the standard INQUIRY data are referenced by name in this standard and SPC-3 
contains a complete definition of the standard INQUIRY data format. 

3.1.116 target: A term used by previous versions of this standard (see Annex B). 

3.1.117 target device name: A SCSI device name (see 3.1.89) of a SCSI target device. See 4.7.2. 

3.1.118 target identifier: A term used by previous versions of this standard (see Annex B). 

3.1.119 target port identifier: A value by which a SCSI target port is referenced within a domain. See 4.7.2. 

3.1.120 target port name: A SCSI port name of a SCSI target port or of a SCSI target/initiator port when 
operating as a SCSI target port. See 4.7.2. 

3.1.121 target/initiator device name: A SCSI device name (see 3.1.89) of a SCSI target/initiator device. See 
4.7.3. 

3.1.122 task: An object within the logical unit representing the work associated with a command or a group of 
linked commands. See 4.11. 

3.1.123 task priority: The relative scheduling importance of a task having a simple task attribute in relation to 
other tasks already in the task set. See 8.7. 

3.1.124 task tag: An object containing up to 64 bits that uniquely identifies each task for a given l_T_L nexus (see 
3.1.45) in a task set (see 3.1.130). See 4.11. 

3.1.125 task management function: A task manager service capable of being requested by an application client 
to affect the processing of one or more tasks. 

3.1.126 task management request: A request submitted by an application client, invoking a task management 
function to be processed by a task manager. 

3.1.127 task management response: The response returned to an application client by a task manager on 
completion of a task management request. 

3.1.128 task manager: A server within a logical unit that controls the sequencing of one or more tasks and 
processes task management functions. 
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3.1.129 task router: An object in a SCSI target port that routes commands and task management functions 
between the service delivery subsystem (see 3.1.113) and the appropriate logical unit’s task manager (see 
3.1.128). 

3.1.130 task set: A group of tasks within a logical unit, whose interaction is dependent on the task management 
(e.g., queuing) and ACA requirements. See 4.8. 

3.1.131 third-party command: A command that requires a logical unit within a SCSI target device to assume the 
SCSI initiator device role and send command(s) to another SCSI target device. 

3.1.132 transaction: A cooperative interaction between two entities, involving the exchange of information or the 
processing of some request by one entity on behalf of the other. 

3.1.133 unconfirmed SCSI transport protocol service: A service available at the SCSI transport protocol 
service interface that does not result in a completion confirmation. See 4.15. 

3.1.134 unlinked command: A command having the link bit set to zero in the CDB control byte that is not the 
last command in a series of linked commands (see 3.1.59). 

3.1.135 well known logical unit: A logical unit that only performs specific functions. Well known logical units 
allow an application client to issue requests to receive and manage specific information relating to a SCSI target 
device. See 4.10. 

3.1.136 well known logical unit number (W-LUN): The logical unit number that identifies a well known logical 
unit. See 4.9.10. 


3.2 Acronyms 

ACA Auto Contingent Allegiance (see 3.1.5) 

CDB Command Descriptor Block (see 3.1.15) 

ISO Organization for International Standards 

LUN Logical Unit Number (see 3.1.64) 

MMC-2 SCSI Multi-Media Commands -2 (see 1.3) 
n/a Not Applicable 

RAID Redundant Array of Independent Disks 

SAL SCSI application layer (see 3.1.86) 

SBC SCSI-3 Block Commands (see 1.3) 

SCSI The architecture defined by the family of standards described in 1.3 
SPI-5 SCSI Parallel Interface -5 (see 1.3) 

SPC-3 SCSI Primary Commands -3 (see 1.3) 

STPL SCSI transport protocol layer (see 3.1.102) 

SSC SCSI-3 Stream Commands (see 1.3) 

VPD Vital Product Data (see SPC-3) 

W-LUN Well known logical unit number (see 3.1.136) 


3.3 Keywords 

3.3.1 invalid: A keyword used to describe an illegal or unsupported bit, byte, word, field or code value. Receipt by 
a device server of an invalid bit, byte, word, field or code value shall be reported as error. 
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3.3.2 mandatory: A keyword indicating an item that is required to be implemented as defined in this standard. 

3.3.3 may: A keyword that indicates flexibility of choice with no implied preference (synonymous with "may or may 
not"). 

3.3.4 may not: A keyword that indicates flexibility of choice with no implied preference (synonymous with "may or 
may not"). 

3.3.5 obsolete: A keyword indicating that an item was defined in prior SCSI standards but has been removed from 
this standard. 

3.3.6 option, optional: Keywords that describe features that are not required to be implemented by this standard. 
However, if any optional feature defined by this standard is implemented, then it shall be implemented as defined in 
this standard. 

3.3.7 SCSI transport protocol specific: Implementation of the referenced item is defined by a SCSI transport 
protocol standard (see 1.3). 

3.3.8 reserved: A keyword referring to bits, bytes, words, fields, and code values that are set aside for future 
standardization. A reserved bit, byte, word, or field shall be set to zero, or in accordance with a future extension to 
this standard. Recipients are not required to check reserved bits, bytes, words, or fields for zero values. Receipt of 
reserved code values in defined fields shall be reported as error. 

3.3.9 shall: A keyword indicating a mandatory requirement. Designers are required to implement all such 
mandatory requirements to ensure interoperability with other products that conform to this standard. 

3.3.10 should: A keyword indicating flexibility of choice with a strongly preferred alternative; equivalent to the 
phrase "it is strongly recommended". 

3.3.11 vendor specific: Specification of the referenced item is determined by the SCSI device vendor. 


3.4 Editorial conventions 

Certain words and terms used in this standard have a specific meaning beyond the normal English meaning. 
These words and terms are defined either in the glossary or in the text where they first appear. 

Upper case is used when referring to the name of a numeric value defined in this specification or a formal attribute 
possessed by an entity. When necessary for clarity, names of objects, procedure calls, arguments or discrete 
states are capitalized or set in bold type. Names of fields are identified using small capital letters (e.g., naca bit). 

Names of procedure calls are identified by a name in bold type, such as Execute Command (see clause 5). 
Names of arguments are denoted by capitalizing each word in the name. For instance, Sense Data is the name of 
an argument in the Execute Command procedure call. 

Quantities having a defined numeric value are identified by large capital letters. CHECK CONDITION, for example, 
refers to the numeric quantity defined in table 22 (see 5.3.1). Quantities having a discrete but unspecified value are 
identified using small capital letters. As an example, task complete, indicates a quantity returned by the Execute 
Command procedure call (see clause 5). Such quantities are associated with an event or indication whose 
observable behavior or value is specific to a given implementation standard. 

Lists sequenced by letters (e.g., a-red, b-blue, c-green) show no priority relationship between the listed items. 
Numbered lists (e.g., 1-red, 2-blue, 3-green) show a priority ordering between the listed items. 
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If a conflict arises between text, tables, or figures, the order of precedence to resolve the conflicts is text; then 
tables; and finally figures. Not all tables or figures are fully described in the text. Tables show data format and 
values. 

Notes do not constitute any requirements for implementors. 


3.5 Numeric conventions 

A binary number is represented in this standard by any sequence of digits comprised of only the Western-Arabic 
numerals 0 and 1 immediately followed by a lower-case b (e.g., 0101 b). Underscores or spaces may be included in 
binary number representations to increase readability or delineate field boundaries (e.g., 0 0101 1010b or 
0_0101_1010b). 

A hexadecimal number is represented in this standard by any sequence of digits comprised of only the 
Western-Arabic numerals 0 through 9 and/or the upper-case English letters A through F immediately followed by a 
lower-case h (e.g., FA23h). Underscores or spaces may be included in hexadecimal number representations to 
increase readability or delineate field boundaries (e.g., B FD8C FA23h or B_FD8C_FA23h). 

A decimal number is represented in this standard by any sequence of digits comprised of only the Western-Arabic 
numerals 0 through 9 not immediately followed by a lower-case b or lower-case h (e.g., 25). 

This standard uses the ISO convention for representing decimal numbers (e.g., the thousands and higher multiples 
are separated by a space and a comma is used as the decimal point). Table 1 shows some examples of decimal 
numbers represented using the ISO and American conventions. 

Table 1 — ISO and American numbering conventions examples 


ISO 

American 

0,6 

0.6 

3,141 592 65 

3.14159265 

1 000 

1,000 

1 323 462,95 

1,323,462.95 
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3.6 Notation conventions 

3.6.1 Hierarchy diagram conventions 

Hierarchy diagrams show how objects are related to each other. The hierarchy diagram of figure 3, for example, 
shows the relationships among the objects comprising an object called Book. For this example, a book object is 
defined as containing a table of contents object, an optional preface object, one or more chapter objects, and an 
optional index object. Further contents definitions are provided for the preface and chapter objects. A preface 
object contains zero or more figure objects, one outline object, and an introductory text object. A chapter object 
contains one or more section objects and zero or more figure objects. 



Figure 3 — Example hierarchy diagram 


In the corresponding hierarchy diagram, labeled boxes denote the above objects. The composition and relation of 
one object to others is shown by the connecting lines. In this case, the connecting lines indicate the relationship 
between the book object and its constituent table of contents, preface, chapter and index objects. Similarly, 
connecting lines show that a chapter object contains section and figure objects. Note that the figure object also 
may be a component of the preface object. 

In the hierarchy diagram, objects that are required to have one and only one instance are shown as simple boxes, 
as is the case for the book and table of contents objects. The hierarchy diagram shows multiple instances of an 
object by the presence of a shadow, as is the case for the chapter, figure and section objects. Objects that are 
optional are indicated by light diagonal lines, as is the case for the preface, figure and index objects. An object that 
may not have any instances, have only one instance, or have multiple instances is shown with both diagonal lines 
and a shadow, as is the case for the figure object. The instance indications shown in a hierarchy diagram are 
approximate; detailed requirements appear in the accompanying text. 
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3.6.2 Notation for procedure calls 

In this standard, the model for functional interfaces between entities is a procedure call (see 3.1.76). Such inter¬ 
faces are specified using the following notation: 

[Result =] Procedure Name (IN ([input-1] [,input-2] ...]), OUT ([output-1] [,output-2]...)) 

Where: 

Result: A single value representing the outcome of the procedure call. 

Procedure Name: A descriptive name for the function modeled by the procedure call. 

Input-1, Input-2, ...: A comma-separated list of names identifying caller-supplied input arguments. 

Output-1, Output-2, ...: A comma-separated list of names identifying output arguments to be returned by the 
procedure call. 

"[...]": Brackets enclosing optional or conditional arguments. 

This notation allows arguments to be specified as inputs and outputs. The following is an example of a procedure 
call specification: 

Found = Search (IN (Pattern, Item List), OUT ([Item Found])) 

Where: 

Found = Flag 

Flag, if set to one, indicates that a matching item was located. 

Input Arguments: 

Pattern = ... /* Definition of Pattern argument 7 

Argument containing the search pattern. 

Item List = ltem<NN> /* Definition of Item List as an array of NN Item arguments*/ 

Contains the items to be searched for a match. 

Output Arguments: 

Item Found = Item ... /* Item located by the search procedure call 7 

This argument is only returned if the search succeeds. 
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3.6.3 Notation for state diagrams 

All state diagrams use the notation shown in figure 4. 


SO: State 0 SI: State 1 

Actions taken on entry to SO Actions taken on entry to SI 



Figure 4 — Example state diagram 

The state diagram is followed by a list of the state transitions, using the transition labels. Each transition is 
described in the list with particular attention to the conditions that cause the transition to occur and special condi¬ 
tions related to the transition. Using figure 4 as an example, the transition list might read as follows: 

Transition S0:S1: This transition occurs when state SO is exited and state SI is entered. 

Transition S1:S0: This transition occurs when state SI is exited and state SO is entered. 

Transition S0:S0: This transition occurs when state SO transitions to itself. The reason for a transition from SO to 
itself is to specify that the actions taken whenever state SO is entered are repeated every time the transition occurs. 

A system specified in this manner has the following properties: 

a) Time elapses only within discrete states; 

b) State transitions are logically instantaneous; and 

c) Every time a state is entered, the actions of that state are started. Note that this means that a transition 
that points back to the same state restarts the actions from the beginning. 
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4 SCSI architecture model 
4.1 Introduction 

The purpose of the SCSI architecture model is to: 

a) Provide a basis for the coordination of SCSI standards development that allows each standard to be 
placed into perspective within the overall SCSI architecture model; 

b) Establish a layered model in which standards may be developed; 

c) Provide a common reference for maintaining consistency among related standards; and 

d) Provide the foundation for application compatibility across all SCSI interconnect and SCSI transport 
protocol environments by specifying generic requirements that apply uniformly to all implementation 
standards within each functional area. 

The development of this standard is assisted by the use of an abstract model. To specify the external behavior of a 
SCSI system, elements in a system are replaced by functionally equivalent components within this model. Only 
externally observable behavior is retained as the standard of behavior. The description of internal behavior in this 
standard is provided only to support the definition of the observable aspects of the model. Those aspects are 
limited to the generic properties and characteristics needed for host applications to interoperate with SCSI devices 
in any SCSI interconnect and SCSI transport protocol environment. The model does not address other require¬ 
ments that may be essential to some I/O system implementations (e.g., the mapping from SCSI device addresses 
to network addresses, the procedure for discovering SCSI devices on a network, and the definition of network 
authentication policies for SCSI initiator devices or SCSI target devices). These considerations are outside the 
scope of this standard. 

The set of SCSI standards specifies the interfaces, functions, and operations necessary to ensure interoperability 
between conforming SCSI implementations. This standard is a functional description. Conforming implementations 
may employ any design technique that does not violate interoperability. 

The SCSI architecture model is described in terms of objects (see 3.1.68), protocol layers, and service interfaces 
between objects. As used in this standard, objects are abstractions, encapsulating a set of related functions, data 
types, and other objects. Certain objects are defined by SCSI (e.g., an interconnect), while others are needed to 
understand the functioning of SCSI but have implementation definitions outside the scope of SCSI (e.g., a task). 
These objects exhibit well-defined and observable behaviors, but they do not exist as separate physical elements. 
An object may be a single numeric parameter (e.g., a task tag) or a complex entity that performs a set of operations 
or services on behalf of another object. 

Service interfaces are defined between distributed objects and protocol layers. The template for a distributed 
service interface is the client-server model described in 4.2. The structure of a SCSI I/O system is specified in 4.4 
by defining the relationship among objects. The set of distributed services to be provided are specified in clause 5 
and clause 7. 

Requirements that apply to each SCSI transport protocol standard are specified in the SCSI transport protocol 
service model described in 5.4, 6.4, and 7.8. The model describes required behavior in terms of layers, objects 
within layers and SCSI transport protocol service transactions between layers. 
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4.2 The SCSI distributed service model 

Service interfaces between distributed objects are represented by the client-server model shown in figure 5. 
Dashed horizontal lines with arrowheads denote a single request-response transaction as it appears to the client 
and server. The solid lines with arrowheads indicate the actual transaction path through the service delivery 
subsystem. In such a model, each client or server is a single thread of processing that runs concurrently with all 
other clients or servers. 



Figure 5 — Client-Server model 


A client-server transaction is represented as a procedure call with inputs supplied by the caller (i.e., the client). The 
procedure call is processed by the server and returns outputs and a procedure call status. A client directs requests 
to a remote server via the SCSI initiator port and service delivery subsystem and receives a completion response 
or a failure notification. The request identifies the server and the service to be performed and includes the input 
data. The response conveys the output data and request status. The function of the service delivery subsystem is 
to transport error-free copies of the requests and responses between sender and receiver. A failure notification 
indicates that a condition has been detected (e.g., a reset or service delivery failure) that precludes request 
completion. 

As seen by the client, a request becomes pending when it is passed to the SCSI initiator port for transmission. The 
request is complete when the server response is received or when a failure notification is sent. As seen by the 
server, the request becomes pending upon receipt and completes when the response is passed to the SCSI target 
port for return to the client. As a result there may be a time skew between the server and client's perception of 
request status and server state. All references to a pending command or task management function in this 
standard are from the application client's point of view (see 5.5 and 5.6). 

Client-server relationships are not symmetrical. A client may only originate requests for service. A server may only 
respond to such requests. 

The client requests an operation provided by a server located in another SCSI device and waits for completion, 
which includes transmission of the request to and response from the remote server. From the client's point of view, 
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the behavior of a service requested from another SCSI device is indistinguishable from a request processed in the 
same SCSI device. In this model, confirmation of successful request or response delivery by the sender is not 
required. The model assumes that delivery failures are detected by the SCSI initiator port or within the service 
delivery subsystem. 


4.3 The SCSI client-server model 

As shown in figure 6, each SCSI target device contains one or more logical units and provides services performed 
by device servers and task management functions performed by task managers. A logical unit is an object that 
implements one of the device functional models described in the SCSI command standards and processes 
commands (e.g., reading from or writing to the media). Each pending command or series of linked commands 
defines a unit of work to be performed by the logical unit. Each unit of work is represented within the SCSI target 
device by a task that may be externally referenced and controlled through requests issued to the task manager. 



Figure 6 — SCSI client-server model 


All requests originate from application clients residing within a SCSI initiator device. An application client is 
independent of the interconnect and SCSI transport protocol (e.g., an application client may correspond to the 
device driver and any other code within the operating system that is capable of managing I/O requests without 
requiring knowledge of the interconnect or SCSI transport protocol). An application client creates one or more 
application client tasks each of which issues a single command, a series of linked commands, or a task 
management function. Application client tasks are part of their parent application client. An application client task 
ceases to exist once the command, series of linked commands, or task management function ends. 

As described in 4.2, each request takes the form of a procedure call with arguments and a status to be returned. 
An application client may request processing of a command through a request directed to the device server within 
a logical unit. Each device service request contains a CDB defining the operation to be performed along with a list 
of command specific inputs and other parameters specifying how the command is to be processed. If supported by 
a logical unit, a series of linked commands may be used to define an extended I/O operation. 

A task is an object within the logical unit representing the work associated with a command or series of linked 
commands. A new command or the first in a series of linked commands causes the creation of a task. The task 
persists until a task complete response is sent or until the task is ended by a task management function or 
exception condition. For an example of the processing for a single command see 5.8.1. For an example of linked 
command processing see 5.8.2. 
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An application client may request processing of a task management function through a request directed to the task 
manager within the logical unit. The interactions between the task manager and application client when a task 
management request is processed are shown in 7.9. 


4.4 The SCSI structural model 

The SCSI structural model represents a view of the elements comprising a SCSI I/O system as seen by the appli¬ 
cation clients interacting with the system. As shown in figure 7, the fundamental object is the SCSI domain that 
represents an I/O system. A domain is made up of SCSI devices and a service delivery subsystem that transports 
commands, data, task management functions, and related information. A SCSI device contains clients or servers 
or both and the infrastructure to support them. 



23 


dpANS SCSI Architecture Model - 3 (SAM-3) 




























21 September 2004 


T10/1561-D revision 14 


Figure 8 shows the main functional components of the SCSI domain. This standard defines these components in 
greater detail. 



Figure 8 — Overall SCSI domain model 


Interconnect 

Subsystem 
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4.5 SCSI domain 

A SCSI domain is composed of at least one SCSI device, at least one SCSI target port and at least one SCSI 
initiator port interconnected by a service delivery subsystem (see figure 9). 


SCSI 

Domain 


Service 

Delivery 

Subsystem 


SCSI 


SCSI 

Initiator Port 


Target Port 


Figure 9 — SCSI domain model 
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A SCSI device (see 4.7) is an object that originates or processes commands and task management functions. 


When a SCSI device originates a command or task management function it is called a SCSI initiator device. The 
commands and task management functions are transmitted through SCSI initiator ports or SCSI target/initiator 
ports. 


A SCSI device containing one or more logical units that process commands is called a SCSI target device. It 
receives commands and task management functions through SCSI target ports or SCSI target/initiator ports. 


The service delivery subsystem connects all the SCSI ports in the SCSI domain, providing a mechanism through 
which application clients communicate with device servers and task managers (see 4.6). 


The boundaries of a SCSI domain are established by the system implementor, within the constraints of a specific 
SCSI transport protocol and associated interconnect standards. 


4.6 The service delivery subsystem 

4.6.1 The service delivery subsystem object 

The service delivery subsystem connects SCSI ports (see 3.1.95) and is composed of one or more interconnects 
that appear to a client or server as a single path for the transfer of requests and responses between SCSI devices. 

The service delivery subsystem is assumed to provide error-free transmission of requests and responses between 
client and server. Although a device driver in a SCSI implementation may perform these transfers through several 
interactions with its SCSI transport protocol layer, the architecture model portrays each operation, from the 
viewpoint of the application client, as occurring in one discrete step. The request or response is: 

a) Considered sent by the sender when the sender passes it to the SCSI port for transmission; 

b) In transit until delivered; and 

c) Considered received by the receiver when it has been forwarded to the receiver via the destination SCSI 
device's SCSI port. 
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4.6.2 Synchronizing client and server states 

One way a client is informed of changes in server state is through the arrival of server responses. Such state 
changes occur after the server has sent the associated response and possibly before the response has been 
received by the SCSI initiator device (e.g., the SCSI target device changes state upon processing the Send 
Command Complete procedure call (see 5.4.2), but the SCSI initiator device is not informed of the state change 
until the Command Complete Received SCSI transport protocol service confirmation arrives). 

SCSI transport protocols may require the SCSI target device to verify that the response has been received 
successfully before completing a state change. State changes controlled in this manner are said to be synchro¬ 
nized. Since synchronized state changes are not assumed or required by the architecture model, there may be a 
time lag between the occurrence of a state change within the SCSI target device and the SCSI initiator device’s 
awareness of that change. 

This standard assumes that state synchronization, if required by a SCSI transport protocol standard, is enforced by 
the service delivery subsystem transparently to the server (i.e., whenever the server invokes a SCSI transport 
protocol service to return a response as described in 7.8 and 5.4. It is assumed that the SCSI port for such a SCSI 
transport protocol does not return control to the server until the response has been successfully delivered to the 
SCSI initiator device). 

4.6.3 Request/Response ordering 

Request or response transactions are said to be in order if, relative to a given pair of sending and receiving SCSI 
ports, transactions are delivered in the order they were sent. 

A sender may require control over the order in which its requests or responses are presented to the receiver (e.g., 
the sequence in which requests are received is often important whenever a SCSI initiator device issues a series of 
commands with the ordered attribute to a logical unit as described in clause 8). In this case, the order in which 
these commands are completed, and hence the final state of the logical unit, may depend on the order in which 
these commands are received. The SCSI initiator device may develop knowledge about the state of pending 
commands and task management functions and may take action based on the nature and sequence of SCSI target 
device responses (e.g., a SCSI initiator device should be aware that further responses are possible from an 
aborted command because the command completion response may be delivered out of order with respect to the 
abort response). 

The manner in which ordering constraints are established is vendor specific. An implementation may delegate this 
responsibility to the application client (e.g., the device driver). In-order delivery may be an intrinsic property of the 
service delivery subsystem or a requirement established by the SCSI transport protocol standard. 

The order in which task management requests are processed is not specified by the SCSI architecture model. The 
SCSI architecture model does not require in-order delivery of such requests or processing by the task manager in 
the order received. To guarantee the processing order of task management requests referencing a specific logical 
unit, an application client should not have more than one such request pending to that logical unit. 

To simplify the description of behavior, the SCSI architecture model assumes in-order delivery of requests or 
responses to be a property of the service delivery subsystem. This assumption does not constitute a requirement. 
The SCSI architecture model makes no assumption about and places no requirement on the ordering of requests 
or responses for different l_T nexuses. 
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4.7 SCSI devices 

A SCSI device is a SCSI target device, a SCSI initiator device, or a SCSI target/initiator device. 

A SCSI initiator device contains at least one SCSI initiator port and is capable of originating commands and task 
management requests (see 4.7.1). A SCSI target device contains at least one SCSI target port, at least one logical 
unit, and is capable of processing commands and task management requests (see 4.7.2). A SCSI target/initiator 
device contains at least one SCSI target/initiator port, at least one logical unit, and is capable of originating and 
processing commands and task management requests (see 4.7.3). 

To be functional, a SCSI domain is required to contain a SCSI target port or a SCSI target/initiator port operating as 
a SCSI target port and a SCSI initiator port or SCSI target/initiator port operating as a SCSI initiator port. 

4.7.1 SCSI initiator device 

A SCSI initiator device (see figure 10) contains: 

a) Zero or more initiator device names; 

b) One or more SCSI initiator ports, each containing an: 

A) Initiator port identifier; and 

B) Optional initiator port name; 

c) One or more application clients; and 

d) Zero or more application client tasks. 



Figure 10 — SCSI initiator device model 


The initiator port identifier is a value that is the SCSI port identifier (see 4.7.4) for a SCSI initiator port. 

An initiator device name is a name (see 3.1.65) that is a SCSI device name (see 4.7.7) for a SCSI initiator device. 
For each supported SCSI transport protocol, a SCSI initiator device shall have no more than one (i.e., zero or one) 
SCSI initiator device name that is not in the SCSI name string format (see SPC-3). A SCSI initiator device shall 
have no more than one (i.e., zero or one) SCSI initiator device name in the SCSI name string format regardless of 
the number of SCSI transport protocols supported by the SCSI initiator device. If a SCSI initiator device has a SCSI 
device name in the SCSI name string format then the SCSI initiator device should have only one SCSI initiator 
device name. A SCSI transport protocol standard may place additional requirements on initiator device names. 

The initiator port name is a name (see 3.1.65) that is the SCSI port name (see 4.7.8) for the SCSI initiator port. A 
SCSI transport protocol standard may place additional requirements on initiator port names. 

Application clients are the sources of commands and task management functions. 
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An application client task is the source for a single command, series of linked commands, or a single task 
management function. 

4.7.2 SCSI target device 

A SCSI target device (see figure 11) contains: 

a) Zero or more target device names; 

b) One or more SCSI target ports, each containing: 

A) A task router; 

B) A target port identifier; 

C) An optional relative port identifier; and 

D) An optional target port name; 
and 

c) One or more logical units. 



Figure 11 — SCSI target device model 


The target port identifier is a value that is a SCSI port identifier (see 4.7.4) for a SCSI target port. 

The relative port identifier (see 4.7.5) identifies the SCSI target port relative to other SCSI ports in the SCSI target 
device. 

A target device name is a name (see 3.1.65) that is a SCSI device name (see 4.7.7) for a SCSI target device. For 
each supported SCSI transport protocol, a SCSI target device shall have no more than one (i.e., zero or one) SCSI 
target device name that is not in the SCSI name string format (see SPC-3). A SCSI target device shall have no 
more than one (i.e., zero or one) SCSI target device name in the SCSI name string format regardless of the 
number of SCSI transport protocols supported by the SCSI target device. If a SCSI target device has a SCSI 
device name in the SCSI name string format then the SCSI target device should have only one SCSI target device 
name. A SCSI transport protocol standard may place additional requirements on target device names. 

The target port name is a name (see 3.1.65) that is the SCSI port name (see 4.7.8) for the SCSI target port. A 
SCSI transport protocol standard may place additional requirements on target port names. 

The task router routes commands and task management functions between the service delivery subsystem and 
the appropriate logical unit’s task manager (see 4.7.6). 

A logical unit is the object to which commands are sent. One of the logical units within the SCSI target device shall 
be accessed using the logical unit number zero or the REPORT LUNS well-known logical unit number. See 4.8 for 
a description of the logical unit. 
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4.7.3 SCSI target/initiator device 

A SCSI target/initiator device contains: 

a) Zero or more target/initiator device names; 

b) One of the following combinations of SCSI ports: 

A) SCSI target/initiator ports present (see figure 12), with: 

a) One or more SCSI target/initiator ports each containing: 

A) A task router; 

B) A target port identifier; 

C) An initiator port identifier; 

D) An optional relative port identifier; 

E) An optional target port name; and 

F) An optional initiator port name; 

b) Zero or more SCSI target ports (see 4.7.2); and 

c) Zero or more SCSI initiator ports (see 4.7.1); 
or 

B) No SCSI target/initiator ports present (see figure 13), with: 

a) Zero SCSI target/initiator ports; 

b) One or more SCSI target ports (see 4.7.2); and 

c) One or more SCSI initiator ports (see 4.7.1); 

c) One or more logical units; and 

d) One or more application clients (see 4.7.1). 



Figure 12 — SCSI target/initiator device with SCSI target/initiator ports model 



Figure 13 — SCSI target/initiator device without SCSI target/initiator ports model 


The target port identifier and the initiator port identifier are values containing a SCSI port identifier (see 4.7.4) for a 
SCSI target/initiator port. The target port identifier and the initiator port identifier may or may not be identical. 
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The relative port identifier (see 4.7.5) identifies the SCSI target port relative to other SCSI ports in the SCSI target 
device. 

A target/initiator device name is a name (see 3.1.65) that is a SCSI device name (see 4.7.7) for a SCSI target/ 
initiator device. For each supported SCSI transport protocol, a SCSI target/initiator device shall have no more than 
one (i.e., zero or one) SCSI target/initiator device name that is not in the SCSI name string format (see SPC-3). A 
SCSI target/initiator device shall have no more than one (i.e., zero or one) SCSI target/initiator device name in the 
SCSI name string format regardless of the number of SCSI transport protocols supported by the SCSI target/ 
initiator device. If a SCSI target/initiator device has a SCSI device name in the SCSI name string format then the 
SCSI target/initiator device should have only one SCSI target/initiator device name. A SCSI transport protocol 
standard may place additional requirements on target/initiator device names. 

The target port name and the initiator port name are names (see 3.1.65) that are the SCSI port name (see 4.7.8) 
for the target/initiator port when operating as a SCSI target port and SCSI initiator port, respectively. The target port 
name and the initiator port name may or may not be identical. A SCSI transport protocol standard may place 
additional requirements on target port names and initiator port names. 

When the SCSI target/initiator device is operating as a SCSI target device the task router routes the commands 
and task management functions between the service delivery subsystem and the appropriate logical unit (see 
4.7.6). 

A logical unit is the object to which commands are sent. One of the logical units within the SCSI target/initiator 
device shall be accessed using the logical unit number zero or the REPORT LUNS well-known logical unit number. 
See 4.8 for a description of the logical unit. 

When the SCSI target/initiator device is operating as a SCSI initiator device an application client is the source of 
commands and task management functions. 

The device server and the application client shall have knowledge of each other's presence in the SCSI target/ 
initiator device and shall cooperate in the processing of one or more SCSI functions. 

4.7.4 SCSI port identifier 

The SCSI port identifier is equivalent to a SCSI identifier (see 3.1.92 and Annex B). The SCSI port identifier object 
represents either an initiator port identifier for a SCSI initiator port, or a target port identifier for a SCSI target port. 
The SCSI port identifier is used when either a SCSI initiator port or SCSI target port is applicable or when other 
context in the description identifies the SCSI initiator port or SCSI target port usage. 

4.7.5 Relative port identifier 

A SCSI target device or a SCSI target/initiator device may assign relative port identifiers to its SCSI ports. If relative 
port identifiers are assigned, the SCSI target device or SCSI target/initiator device shall assign each of its SCSI 
ports a unique relative port identifier from 1 to 65 535. SCSI target ports, SCSI target/initiator ports, and SCSI 
initiator ports share the same number space. 

Relative port identifiers may be retrieved through the Device Identification VPD page (see SPC-3) and the SCSI 
Ports VPD page (see SPC-3). 

The relative port identifiers are not required to be contiguous. The relative port identifier for a SCSI port shall not 
change once assigned unless physical reconfiguration of the SCSI target device occurs. 


dpANS SCSI Architecture Model - 3 (SAM-3) 


30 



T10/1561-D revision 14 


21 September 2004 


4.7.6 SCSI task router 

The task router routes commands and task management functions to the selected logical unit. Any task that is sent 
to a logical unit that is not known to the task router is handled as described in 5.9.4. 

4.7.7 SCSI device name 

A SCSI device name is an optional name (see 3.1.65) for a SCSI device that is world wide unique within the SCSI 
transport protocol of each SCSI domain in which the SCSI device has SCSI ports. For each supported SCSI 
transport protocol, a SCSI device shall have no more than one (i.e., zero or one) SCSI device name that is not in 
the SCSI name string format (see SPC-3). A SCSI device shall have no more than one (i.e., zero or one) SCSI 
device name in the SCSI name string format regardless of the number of SCSI transport protocols supported by 
the SCSI device. If a SCSI device has a SCSI device name in the SCSI name string format then the SCSI device 
should have only one SCSI device name. A SCSI device name shall never change and may be used to persistently 
identify a SCSI device in contexts where specific references to port names or port identifiers is not required. 

A SCSI transport protocol standard may require that a SCSI device include a SCSI device name if the SCSI device 
has SCSI ports in a SCSI domain of that SCSI transport protocol. The SCSI device name may be made available to 
other SCSI devices or SCSI ports in a given SCSI domain in SCSI transport protocol specific ways. 

4.7.8 SCSI port name 

A SCSI port name is an optional name (see 3.1.65) of a SCSI port that is world wide unique within the SCSI 
transport protocol of the SCSI domain of that SCSI port. A SCSI port may have at most one name. A SCSI port 
name shall never change and may be used to persistently identify a SCSI initiator port or SCSI target port in 
contexts similar to those where a SCSI port identifier (see 4.7.4) may be used. 

A SCSI transport protocol standard may require that a SCSI port include a SCSI port name if the SCSI port is in a 
SCSI domain of that SCSI transport protocol. The SCSI port name may be made available to other SCSI devices or 
SCSI ports in the given SCSI domain in SCSI transport protocol specific ways. 
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4.8 Logical units 

A logical unit (see figure 14) represents a physical or logical device and contains: 

a) Logical unit number(s), required as follows: 

A) If access controls (see SPC-3) are not in effect, one logical unit number per logical unit; or 

B) If access controls are in effect, one logical unit number per SCSI initiator port that has access rights 
plus one default logical unit number per logical unit; 

b) Logical unit name(s), required as follows: 

A) One or more logical unit names if the logical unit is not a well-known logical unit; or 

B) Zero logical unit names in the logical unit is a well-known logical unit; 

c) A device server; 

d) A task manager; and 

e) One or more task sets each of which contains zero or more tasks. 



Figure 14 — Logical unit model 


A logical unit number (see 4.9) is a field containing 64 bits or 16 bits that identifies the logical unit within a SCSI 
target device when accessed by a SCSI target port. If any logical unit within the scope of a SCSI target device 
includes one or more dependent logical units (see 3.1.23) in its composition, then all logical unit numbers within the 
scope of the SCSI target device shall have the format described in 4.9.5. If there are no dependent logical units 
within the scope of the SCSI target device, the logical unit numbers should have the format described in 4.9.4. 

A logical unit name is a name (see 3.1.65) for a logical unit that is not a well known logical unit. A logical unit name 
shall be world wide unique. A logical unit name shall never change and may be used to persistently identify a 
logical unit. 

The device server is the object that processes tasks (see 4.11). There is one device server per logical unit. 

The task manager controls the sequencing of one or more tasks within a logical unit. The task manager also 
processes the task management functions specified in clause 7. There is one task manager per logical unit. 

A task set is composed of zero or more tasks (see 4.11). 

The interactions among the tasks in a task set are determined by the requirements for task set management 
specified in clause 8 and the ACA requirements specified in 5.9.1. The number of task sets per logical unit and the 
boundaries between task sets are governed by the tst field in the Control mode page (see SPC-3). 
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4.9 Logical unit numbers 

4.9.1 Introduction 

Subclause 4.9 defines the construction of logical unit numbers to be used by SCSI target devices. Application 
clients should use only those logical unit numbers returned by a REPORT LUNS command. The device server 
shall respond to logical unit numbers other than those returned by a REPORT LUNS command as specified in 
5.9.4. 

The 64-bit quantity called a LUN is the logical unit number object defined by this standard. The fields containing the 
acronym LUN that compose the logical unit number object are historical nomenclature anomalies, not logical unit 
number objects. Logical unit number objects having different values represent different logical units, regardless of 
any implications to the contrary in 4.9 (e.g., LUN 00000000 OOOOOOOOh is a different logical unit from LUN 
40000000 OOOOOOOOh and LUN 00FF0000 OOOOOOOOh is a different logical unit from LUN 40FF0000 OOOOOOOOh). 

4.9.2 Logical unit numbers overview 

All logical unit number formats described in this standard are hierarchical in structure even when only a single level 
in that hierarchy is used. The HiSup bit shall be set to one in the standard INQUIRY data (see SPC-3) when any 
logical unit number format described in this standard is used. Non-hierarchical formats are outside the scope of this 
standard. 

A logical unit number shall contain 64 bits or 16 bits, with the size being defined by the SCSI transport protocol. For 
SCSI transport protocols that define 16-bit logical unit numbers, the two bytes shall be formatted as described for 
the first level addressing field (see table 5 in 4.9.5). 

4.9.3 Minimum LUN addressing requirements 

All SCSI devices shall support LUN 0 (i.e., 00000000 OOOOOOOOh) or the REPORT LUNS well-known logical unit. 
For SCSI devices that support the hierarchical addressing model the LUN 0 or the REPORT LUNS well-known 
logical unit shall be the logical unit that an application client addresses to determine information about the SCSI 
target device and the logical units contained within the SCSI target device. 

The responses to commands sent to unsupported logical units are defined in 5.9.4. The response to task 
management functions sent to unsupported logical units is defined in 7.1. 
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4.9.4 Single level logical unit number structure 

Table 2 describes a single level subset of the format described in 4.9.5 for logical unit numbers 255 and below. 


Table 2 — Single level logical unit number structure for logical unit numbers 255 and below 


Bit 

Byte 

7 6 

5 4 3 2 1 0 

0 

ADDRESS METHOD (00b) 

BUS IDENTIFIER (00h) 

1 

SINGLE LEVEL LUN (00h to FFh, inclusive) 

2 

(MSB) .. 

3 

(LSB) 

4 

(MSB) Nu ll th j rd | eve | LUN (0000h) 

5 

(LSB) 

6 

(MSB) Null fourth level LUN (OOOOh) 

7 

(LSB) 


All logical unit number structure fields shall be zero except the single level LUN field (see table 2). The value in 
the single level LUN field shall be between 0 and 255, inclusive. The 00b in the address method field specifies 
peripheral device addressing (see 4.9.5) and the OOh in the bus identifier field specifies the current level (see 
4.9.6). 

Table 3 describes a single level subset of the format described in 4.9.5 for logical unit numbers 16 383 and below. 


Table 3 — Single level logical unit number structure for logical unit numbers 16 383 and below 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

ADDRESS METHOD (01b) 

(MSB) 

single level LUN (OOOOh to 3FFFh, inclusive) 


1 


(LSB) 

2 

(MSB) 

Null second level LUN (OOOOh) 


3 


(LSB) 

4 

(MSB) 

Null third level LUN (OOOOh) 


5 


(LSB) 

6 

(MSB) 

Null fourth level LUN (OOOOh) 


7 


(LSB) 


All logical unit number structure fields shall be zero except the single level LUN field (see table 3). The value in 
the single level LUN field shall be between 0 and 16 383, inclusive. The 01b in the address method field 
specifies flat space addressing (see 4.9.7) at the current level. 


If a SCSI target device contains 256 or fewer logical units, none of which are dependent logical units (see 4.14) or 
extended addressing logical units (see 4.9.9), then its logical units should be numbered 255 and below, and should 
have the format shown in table 2 (i.e., peripheral device addressing) but may have the format shown in table 3 (i.e., 
flat space addressing). 
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If a SCSI target device contains 16 384 or fewer logical units, none of which are dependent logical units or 
extended addressing logical units, then its logical units should be numbered 16 383 and below, and should have 
the format shown in table 3 (i.e., flat space addressing) but may have the format shown in table 2 (i.e., peripheral 
device addressing) for logical unit numbers that are less than 256. 

4.9.5 Eight byte logical unit number structure 

The eight byte logical unit number structure (see table 5) contains four levels of addressing fields. Each level shall 
use byte 0 and byte 1 to define the address and/or location of the SCSI device to be addressed on that level. 

If the logical unit number specifies that the command is to be relayed to the next layer then the current layer shall 
use byte 0 and byte 1 of the eight byte logical unit number structure to determine the address of the SCSI device to 
which the command is to be sent. When the command is sent to the SCSI target device the eight byte logical unit 
number structure that was received shall be adjusted to create a new eight byte logical unit number structure (see 
table 4 and figure 15). 

SCSI devices shall keep track of the addressing information necessary to transmit information back through all 
intervening layers to the task’s originating SCSI initiator port. 



Figure 15 — Eight byte logical unit number structure adjustments 


Table 4 — Eight byte logical unit number structure adjustments 
Byte position 
Old New 

0 & 1 Moves to Not Used 

2 & 3 Moves to 0 & 1 

4 & 5 Moves to 2 & 3 

6 & 7 Moves to 4 & 5 

N/A zero fill 6 & 7 
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The eight byte logical unit number structure requirements as viewed from the application client are shown in table 
5. 


Table 5 — Eight byte logical unit number structure 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 


FIRST LEVEL ADDRESSING 


1 



2 


SECOND LEVEL ADDRESSING 


3 



4 


THIRD LEVEL ADDRESSING 


5 



6 


FOURTH LEVEL ADDRESSING 


7 




The first level addressing field specifies the first level address of a SCSI device. See table 6 for a definition of 

the FIRST LEVEL ADDRESSING field. 

The second level addressing field specifies the second level address of a SCSI device. See table 6 for a 
definition of the second level addressing field. 

The third level addressing field specifies the third level address of a SCSI device. See table 6 for a definition of 

the THIRD LEVEL ADDRESSING field. 

The fourth level addressing field specifies the fourth level address of a SCSI device. See table 6 for a definition 

of the FOURTH LEVEL ADDRESSING field. 


Table 6 — Format of addressing fields 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

n-1 

ADDRESS METHOD 






n 




ADDRESS METHOD SPECIFIC 



The address method field defines the contents of the address method specific field. See table 7 for the address 
methods defined for the address method field. The address method field only defines address methods for 
entities that are directly addressable by an application client. 


Table 7 — address method field values 


Code 

Description 

Reference 

00b 

Peripheral device addressing method 

4.9.6 

01b 

Flat space addressing method 

4.9.7 

10b 

Logical unit addressing method 

4.9.8 

11b 

Extended logical unit addressing method 

4.9.9 
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4.9.6 Peripheral device addressing method 

If the peripheral device addressing method (see table 8) is selected, the SCSI device should relay the received 
command or task management function to the addressed dependent logical unit. Any command that is not relayed 
to a dependent logical unit shall be terminated with a CHECK CONDITION status. The sense key shall be set to 
ILLEGAL REQUEST and the additional sense code shall be set to INVALID COMMAND OPERATION CODE. If a 
task management function cannot be relayed to a dependent logical unit, a service response of service delivery 
or TARGET failure shall be returned. 

NOTE 1 - A SCSI device may filter (i.e., not relay) commands or task management functions to prevent operations 
with deleterious effects from reaching a dependent logical unit (e.g., a WRITE command directed to a logical unit 
that is participating in a RAID volume). 


Table 8 — Peripheral device addressing 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

n-1 

ADDRESS METHOD (00b) 

BUS IDENTIFIER 

n 

TARGET OR LUN 


The bus identifier field identifies the bus or path that the SCSI device shall use to relay the received command or 
task management function. The bus identifier field may use the same value encoding as the bus number field 
(see 4.9.8) with the most significant bits set to zero. However, bus identifier zero shall specify that the command or 
task management function is to be relayed to a logical unit within the SCSI device at the current level. 

The target or lun field specifies the address of the peripheral device (e.g., a SCSI device at the next level in the 
hierarchy) to which the SCSI device shall relay the received command or task management function. The meaning 
and usage of the target or lun field depends on whether the bus identifier field contains zero. 

A bus identifier field of zero specifies a logical unit at the current level. This representation of a logical unit may be 
used either when the SCSI device at the current level does not use hierarchical addressing for assigning LUNs to 
entities or when the SCSI device at the current level includes entities that are assigned LUNs but are not attached 
to SCSI buses. When the bus identifier field contains zero, the command or task management function shall be 
relayed to the current level logical unit specified by the target or lun field within or joined to the current level SCSI 
device. 

A bus identifier field greater than zero represents a SCSI domain that connects a group of SCSI devices to the 
current level SCSI device. Each SCSI domain shall be assigned a unique bus identifier number from 1 to 63. These 
bus identifiers shall be used in the bus identifier field when assigning addresses to peripheral devices attached to 
the SCSI domains. When the bus identifier field is greater than zero, the command or task management function 
shall be relayed to the logical unit with the logical unit number zero within the SCSI target device specified in the 
target or lun field located in the SCSI domain specified by the bus identifier field. The SCSI target device infor¬ 
mation in the target or lun field is a mapped representation of a target port identifier. 

The SCSI device located within the current level may be addressed by a bus identifier field and a target or lun 
field of all zeros, also known as LUN 0 (see 4.9.3). 
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4.9.7 Flat space addressing method 

The flat space addressing method (see table 9) specifies a logical unit at the current level. 

The contents of all hierarchical structure addressing fields following a flat space addressing method addressing 
field shall be ignored. 


Table 9 — Flat space addressing 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

n-1 

ADDRESS METHOD (01b) 

(MSB) 





n 




LUN 


(LSB) 


The lun field specifies the current level logical unit. 

4.9.8 Logical unit addressing method 

If the logical unit addressing method (see table 10) is selected, the SCSI device should relay the received 
command or task management function to the addressed dependent logical unit. Any command that is not relayed 
to a dependent logical unit shall be terminated with a CHECK CONDITION status. The sense key shall be set to 
ILLEGAL REQUEST and the additional sense code shall be set to INVALID COMMAND OPERATION CODE. If a 
task management function cannot be relayed to a dependent logical unit, a service response of service delivery 
or TARGET failure shall be returned. 

NOTE 2 - A SCSI device may filter (i.e., not relay) commands or task management functions to prevent operations 
with deleterious effects from reaching a dependent logical unit (e.g., a WRITE command directed to a logical unit 
that is participating in a RAID volume). 

The contents of all hierarchical structure addressing fields following a logical unit addressing method addressing 
field shall be ignored. 


Table 10 — Logical unit addressing 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

n-1 

ADDRESS METHOD (10b) 

TARGET 

n 

BUS NUMBER LUN 


The target field, bus number field, and lun field address the logical unit to which the received command or task 
management function shall be relayed. The command or task management function shall be relayed to the logical 
unit specified by the lun field within the SCSI target device specified by the target field located on the bus 
specified by the bus number field. The value in the lun field shall be placed in the least significant bits of the single 
level LUN field in a single level logical unit number structure for logical unit numbers 255 and below (see 4.9.2). 
The target field contains a mapped representation of a target port identifier. 
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4.9.9 Extended logical unit addressing 

Extended logical unit addressing (see table 11) specifies a logical unit at the current level. 

Extended logical unit addressing builds on the formats defined for dependent logical units (see 4.14) but may be 
used by SCSI devices having single level logical unit structure. In dependent logical unit addressing, the logical unit 
information at each level fits in exactly two bytes. Extended logical unit addresses have sizes of two bytes, four 
bytes, six bytes, or eight bytes. 

The contents of all hierarchical structure addressing fields following an extended logical unit addressing method 
addressing field shall be ignored. 

Extended logical units are identified by the address method field (see table 7 in 4.9.5) in the same manner as is 
the case for dependent logical units. An address method field value of 11b specifies the extended logical unit 
addressing method. 


Table 11 — Extended logical unit addressing 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

n 

ADDRESS METHOD (11b) 

LENGTH 

EXTENDED ADDRESS METHOD 

m 

EXTENDED ADDRESS METHOD SPECIFIC 


The length field (see table 12) specifies the length of the extended address method specific field. 


Table 12 — length field values and related sizes 


Value 

Size in bytes of 

Reference 

EXTENDED 

ADDRESS METHOD 

specific field 

Extended logical 
unit addressing 
format 

00b 

1 

2 

table 13 

01b 

3 

4 

table 14 

10b 

5 

6 

table 15 

11b 

7 

8 

table 16 


Table 13, table 14, table 15, and table 16 show the four extended logical unit addressing formats. 


Table 13 — Two byte extended logical unit addressing format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

n 

ADDRESS METHOD (11b) 

LENGTH (00b) 

EXTENDED ADDRESS METHOD 

n+1 

EXTENDED ADDRESS METHOD SPECIFIC 
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Table 14 — Four byte extended logical unit addressing format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

n 

ADDRESS METHOD (11b) 

LENGTH (01b) 

EXTENDED ADDRESS METHOD 

n+1 

(MSB) 

EXTENDED ADDRESS METHOD SPECIFIC 


n+3 


(LSB) 


Table 15 — Six byte extended logical unit addressing format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

n 

ADDRESS METHOD (11b) 

LENGTH (10b) 

EXTENDED ADDRESS METHOD 

n+1 

(MSB) 

EXTENDED ADDRESS METHOD SPECIFIC 


n+5 


(LSB) 


Table 16 — Eight byte extended logical unit addressing format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

ADDRESS METHOD (11b) 

LENGTH (11b) 

EXTENDED ADDRESS METHOD 

1 

(MSB) 

EXTENDED ADDRESS METHOD SPECIFIC 


7 


(LSB) 


The extended address method field combined with the length field (see table 17) specifies the type and size of 
extended logical unit address found in the extended address method specific field. 


Table 17 — Logical unit extended addressing 


EXTENDED ADDRESS 

method Code(s) 

LENGTH 

Code(s) 

Description 

Reference 

Oh 

00b- 11b 

Reserved 


1h 

00b 

Well known logical unit 

4.9.10 

1h 

01b- 11b 

Reserved 


-C 

LU 

-C 

00b- 11b 

Reserved 


Fh 

00b- 10b 

Reserved 


Fh 

11b 

Logical unit not specified 

4.9.11 


4.9.10 Well known logical unit addressing 

A SCSI target device may support zero or more well known logical units (see 4.10). A single SCSI target device 
shall only support one instance of each supported well known logical unit. All well known logical units within a SCSI 
target device shall be accessible from all SCSI target ports contained within the SCSI target device. 
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Well known logical units are addressed using the well known logical unit extended address format (see table 18). 

Table 18 — Well known logical unit extended address format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

n 

ADDRESS METHOD (11b) 

LENGTH (00b) 

EXTENDED ADDRESS METHOD (1h) 

n+1 

W-LUN 


The w-lun field specifies the well known logical unit to be addressed (see SPC-3). 


4.9.11 Logical unit not specified addressing 

Logical unit not specified addressing (see table 19) shall be used to indicate that no logical unit of any kind is 
specified. 


Table 19 — Logical unit not specified extended address format 


Bit 

Byte 

7 6 

5 4 

3 2 10 

0 

ADDRESS METHOD (11b) 

LENGTH (11b) 

EXTENDED ADDRESS METHOD (Fh) 

1 

FFh 

2 

FFh 

3 

FFh 

4 

FFh 

5 

FFh 

6 

FFh 

7 

FFh 


4.10 Well known logical units 

A well known logical unit is identical to a logical unit (see 4.8) except as defined in this subclause. 

Well known logical units are addressed using the well known logical unit addressing method (see 4.9.10) of 
extended logical unit addressing (see 4.9.9). Each well known logical unit has a well known logical unit number 
(W-LUN). W-LUN values are defined in SPC-3. 

If a SCSI target device receives a W-LUN and the well known logical unit specified by the W-LUN does not exist, a 
task manager shall follow the rules for selection of incorrect logical units described in 5.9.4. 

If a well known logical unit is supported within a SCSI target device then that logical unit shall support all the 
commands defined for it. 

Access to well known logical units shall not be affected by access controls. 
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All well known logical units: 

a) Shall not have logical unit names; and 

b) Shall identify themselves using the SCSI target device names or SCSI target/initiator device names of the 
SCSI target device or SCSI target/initiator device in which they are contained. 

NOTE 3 - A SCSI target device may have multiple SCSI target device names if the SCSI target device supports 
multiple SCSI transport protocols (see 4.7.2). SCSI target/initiator device may have multiple SCSI target/initiator 
device names if the SCSI target/initiator device supports multiple SCSI transport protocols (see 4.7.3). 

The name of the well known logical unit may be determined by issuing an INQUIRY command requesting the 
Device Identification VPD page (see SPC-3). 


4.11 Tasks and task tags 

A task is represented by an l_T_L_Q nexus (see 4.12) and is composed of: 

a) A definition of the work to be performed by the logical unit in the form of a command or a group of linked 
commands; 

b) A task attribute (see 8.6) that allows the application client to specify processing relationships between 
various tasks in the task set; and 

c) Optionally, a task priority (see 8.7). 

The l_T_L_Q nexus representing a task includes a task tag, allowing many uniquely identified tagged tasks to be 
present in a single task set. A task tag is a value that is composed of up to 64 bits. 

A SCSI initiator device assigns task tag values for each l_T_L_Q nexus in a way that ensures that the nexus 
uniqueness requirements stated in this subclause are met. Transport protocols may define additional restrictions 
on task tag assignment (e.g., restricting task tag length, requiring task tags to be unique per l_T nexus or per l_T_L 
nexus, or sharing task tag values with other uses such as task management functions). 

An l_T_L_Q nexus that is in use (i.e., during the interval bounded by the events specified in 5.5) shall be unique as 
seen by the SCSI initiator port originating the command and the logical unit to which the command was addressed, 
otherwise an overlapped command condition exists (see 5.9.3). An l_T_L_Q nexus is unique if one or more of its 
components is unique within the specified time interval. 

A SCSI initiator device shall not create more than one task from a specific SCSI initiator port having identical 
values for the target port identifier, logical unit number, and task tag. 
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4.12 The nexus object 

The nexus object represents a relationship between a SCSI initiator port, a SCSI target port, optionally a logical 
unit, and optionally a task. 

The nexus object may refer to any one or all of the following relationships: 

a) One SCSI initiator port to one SCSI target port (an l_T nexus); 

b) One SCSI initiator port to one SCSI target port to one logical unit (an l_T_L nexus); 

c) One SCSI initiator port to one SCSI target port to one logical unit to one task (an l_T_L_Q nexus); or 

d) Either an l_T_L nexus or an l_T_L_Q nexus (denoted as an l_T_L_x nexus). 

Table 20 maps the nexus object to other identifier objects. 


Table 20 — Mapping nexus to SAM-2 identifiers 


Nexus 

Identifiers contained in nexus 

Reference 

l_T 

Initiator Port Identifier 

4.7.1 


Target Port Identifier 

4.7.2 

l_T_L 

Initiator Port Identifier 

4.7.1 


Target Port Identifier 

4.7.2 


Logical Unit Number 

4.8 

l_T_L_Q 

Initiator Port Identifier 

4.7.1 


Target Port Identifier 

4.7.2 


Logical Unit Number 

4.8 


Task Tag 

4.11 
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4.13 SCSI ports 

4.13.1 SCSI port configurations 

A SCSI device may contain only SCSI target ports, only SCSI initiator ports, only SCSI target/initiator ports or any 
combination of ports. Some of the port configurations possible for a SCSI device are shown in figure 16. 
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Figure 16 — SCSI device functional models 


A SCSI target/initiator device is referred to by the role its port takes when it participates in an I/O operation. When 
a SCSI target/initiator device receives commands or task management functions, the SCSI target/initiator device 
takes on the characteristics of and is referred to as a SCSI target device. When a SCSI target/initiator device 
issues commands or task management functions, the SCSI target/initiator device takes on the characteristics of 
and is referred to as a SCSI initiator device. 


4.13.2 SCSI devices with multiple ports 

The model for a SCSI device with multiple ports is a single SCSI target device (see 4.7.2), SCSI initiator device 
(see 4.7.1), or SCSI target/initiator device (see 4.7.3) with multiple ports. 

The SCSI identifiers representing the ports shall meet the requirements for initiator port identifiers (see 4.7.1) or 
target port identifiers (see 4.7.2) or both. SCSI target/initiator devices with multiple ports implement both target and 
initiator models and combine the SCSI target/initiator port structures in vendor specific ways while maintaining the 
model for SCSI devices with multiple ports for the target and initiator functions. How a multiple port SCSI device is 
viewed by counterpart SCSI devices in the SCSI domain also depends on whether a SCSI initiator port is 
examining a SCSI target port or SCSI target/initiator port, or a SCSI target port is servicing a SCSI initiator port or 
SCSI target/initiator port. 
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4.13.3 Multiple port SCSI target device structure 

Figure 17 shows the structure of a SCSI target device with multiple SCSI target ports. Each SCSI target port 
consists of a task router that is shared by a collection of logical units. Each logical unit contains a single task 
manager and a device server. 



Figure 17 — Multiple port target SCSI device structure model 


Two-way communications shall be possible between all logical units and all SCSI target ports, however, communi¬ 
cations between any logical unit and any SCSI target port may be inactive. Two-way communications shall be 
available between each task manager and all task routers. Each SCSI target port shall accept commands sent to 
LUN 0 or the REPORT LUNS well-know logical unit and the task router shall route them to a device server for 
processing. The REPORT LUNS commands (see SPC-3) shall be accepted by the logical unit with the logical unit 
number zero or the REPORT LUNS well-known logical unit from any SCSI target port and shall return the logical 
unit inventory available via that SCSI target port. The availability of the same logical unit through multiple SCSI 
target ports is discovered by matching logical unit name values in the INQUIRY command Device Identification 
VPD page (see SPC-3). 
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4.13.4 Multiple port SCSI initiator device structure 

Figure 18 shows the structure of a SCSI initiator device with multiple SCSI initiator ports. Each SCSI initiator port is 
shared by a collection of application clients. 



Two-way communications shall be possible between an application client and its associated SCSI initiator port. 
This standard does not specify or require the definition of any mechanisms by which a SCSI target device would 
have the ability to discover that it is communicating with multiple ports on a single SCSI initiator device. In those 
SCSI transport protocols where such mechanisms are defined, they shall not have any effect on how commands 
are processed (e.g., reservations shall be handled as if no such mechanisms exist). 
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4.13.5 Multiple port SCSI target/initiator device structure 

Figure 19 shows the structure of a SCSI target/initiator device with multiple SCSI target/initiator ports. A SCSI 
target/initiator device may also contain SCSI target ports and SCSI initiator ports. Each SCSI target/initiator port 
consists of a task router and is shared by a collection of logical units and application clients. Each logical unit 
contains a task manager and a device server. 



Figure 19 — Multiple port target/initiator SCSI device structure model 


Two-way communications shall be possible between all logical units and all SCSI target/initiator ports, however, 
communications between any logical unit and any SCSI target/initiator port may be inactive. Two-way communica¬ 
tions shall be possible between an application client and its associated SCSI target/initiator port. Each SCSI target/ 
initiator port shall accept commands sent to LUN 0 or the REPORT LUNS well-know logical unit and the task router 
shall route them to a device server for processing. The REPORT LUNS commands (see SPC-3) shall be accepted 
by the logical unit with the logical unit number zero or the REPORT LUNS well-known logical unit from any SCSI 
target/initiator port and shall return the logical unit inventory available via that SCSI target/initiator port. The avail¬ 
ability of the same logical unit through multiple SCSI target/initiator ports is discovered by matching logical unit 
name values in the INQUIRY command Device Identification VPD page (see SPC-3). 

This standard does not specify or require the definition of any mechanisms by which a SCSI target device would 
have the ability to discover that it is communicating with multiple SCSI initiator ports on a single SCSI target/initiator 
device. In those SCSI transport protocols where such mechanisms are defined, they shall not have any effect on 
how commands are processed (e.g., reservations shall be handled as if no such mechanisms exist). 
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4.13.6 SCSI initiator device view of a multiple port SCSI target device 

A SCSI target device may be connected to multiple SCSI domains such that a SCSI initiator port is only able to 
communicate with its logical units using a single SCSI target port. However, SCSI target devices with multiple SCSI 
ports may be configured where application clients have the ability to discover that one or more logical units are 
accessible via multiple SCSI target ports. Figure 20 and figure 21 show two examples of such configurations. 

Figure 20 shows a SCSI target device with multiple SCSI target ports participating in a single SCSI domain with 
two SCSI initiator devices. There are three SCSI devices, one of which has two SCSI target ports, and two of which 
have one SCSI initiator port each. There are two target port identifiers and two initiator port identifiers in this SCSI 
domain. Using the INQUIRY command Device Identification VPD page (see SPC-3), the application clients in each 
of the SCSI initiator device have the ability to discover the logical units in the SCSI target devices are accessible via 
multiple SCSI target ports and map the configuration of the SCSI target device. 


SCSI Domain 


Service 

Delivery 

Sub¬ 

system 


Figure 20 — SCSI target device configured in a single SCSI domain 
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Figure 21 shows a SCSI target device with multiple SCSI target ports participating in two SCSI domains and a 
SCSI initiator device with multiple SCSI initiator ports participating in the same two SCSI domains. There is one 
SCSI target device with two SCSI target ports and one SCSI initiator device with two SCSI initiator ports. There is 
one target port identifier and one initiator port identifier in each of the two SCSI domains. Using the INQUIRY 
command Device Identification VPD page (see SPC-3), the application clients in the SCSI initiator device have the 
ability to discover that logical units in the SCSI target device are accessible via multiple SCSI initiator ports and 
multiple SCSI target ports and map the configuration. However, application clients may not be able to distinguish 
between the configuration shown in figure 21 and the configuration shown in figure 22. 
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Figure 22 shows the same configuration as figure 21 except that the two SCSI domains have been replaced by a 
single SCSI domain. 



Figure 22 — SCSI target device and SCSI initiator device configured in a single SCSI domain 


This model for application client determination of multiple SCSI target port configurations relies on information that 
is available only to the application clients via commands. 

4.13.7 SCSI target device view of a multiple port SCSI initiator device 

This standard does not require a SCSI target device to have the ability to detect the presence of a SCSI initiator 
device with multiple SCSI initiator ports. Therefore, a SCSI target device handles a SCSI initiator device with 
multiple SCSI initiator ports exactly as it would handle multiple separate SCSI initiator devices (e.g., a SCSI target 
device handles the configurations shown in figure 21 and figure 22 in exactly the same way it handles the configu¬ 
ration shown in figure 20). 

NOTE 4 - The implications of this view of a SCSI initiator device are more far reaching than are immediately 
apparent (e.g., after a SCSI initiator device makes a persistent exclusive access reservation via one SCSI initiator 
port, access is denied to the other SCSI initiator port(s) on that same SCSI initiator device). 
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4.14 Model for dependent logical units 

Optionally, the model for a logical unit (see 4.8) may include one or more unique logical units embedded within 
another logical unit. The embedded logical units are called dependent logical units (see 3.1.23). In such cases, the 
model hierarchy diagram in 4.8 is modified to become the diagram shown in figure 23. 
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Figure 23 — Dependent logical unit model 

When the dependent logical unit model is utilized, the hierarchical logical unit number structure defined in 4.9.5 
shall be used. If any logical unit within a SCSI target device includes dependent logical units, all logical unit 
numbers within the SCSI target device shall have the format described in 4.9.5. A device server that implements 
the hierarchical structure for dependent logical units described in this subclause shall set the HiSup bit to one in the 
standard INGUIRY data returned by the logical unit with the logical unit number zero or by the REPORT LUNS 
well-known logical unit (see SPC-3). 

The hierarchical logical unit structure is an inverted tree containing up to four addressable levels. The example in 
figure 24 is a three-level system that consists of: 

a) One SCSI initiator device that has three SCSI target devices attached in a single SCSI domain that is 
unable to add more SCSI target devices. One of the SCSI target devices is the level 1 SCSI device with 
dependent logical units (SDDLU). The level 1 SDDLU has two SCSI target ports, one in each of the SCSI 
domains containing a SCSI initiator device; 

b) One SCSI initiator device has three SCSI target devices attached in a single SCSI domain that is able to 
add more SCSI target devices. One of the SCSI target devices is the level 1 SDDLU; and 

c) The level 1 SDDLU has three SCSI domains (called buses for hierarchical addressing purposes) with SCSI 
target devices attached and is capable of connecting more SCSI domains; 

A) Two of the SCSI domains contain two SCSI target devices each and these SCSI domains are unable 
to add more SCSI target devices. One of the SCSI target devices is the level 2 SDDLU; 

B) One of the SCSI domains contains two SCSI target devices and is able to add more SCSI target 
devices; and 

C) The level 2 SDDLU has three SCSI domains with SCSI target devices attached and is capable of 
connecting more SCSI domains; 

a) Two of the SCSI domains contain two SCSI target devices each and these SCSI domains are 
unable to add more SCSI target devices; and 

b) One of the SCSI domains contains two SCSI target devices and is able to add more SCSI target 
devices. 
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Key: • • • indicates the ability to add more components 


Figure 24 — Example of hierarchical system diagram 

SCSI devices at each level in the hierarchical logical unit structure are referenced by one of the following address 
methods: 


a) Peripheral device address method (see 4.9.6); 

b) Flat space addressing method (see 4.9.7); 

c) Logical unit address method (see 4.9.8); or 

d) Extended logical unit addressing method (see 4.9.9). 

All peripheral device addresses, except LUN 0 (see 4.9.3), default to vendor specific values. All addressable 
entities, except well known logical units (see 4.10), may default to vendor specific values or may be defined by an 
application client (e.g., by the use of SCC-2 configuration commands). 

Within the hierarchical system there may be SCSI target devices that have multiple logical units connected to them 
through separate SCSI initiator ports. The SCSI domains accessed by these SCSI initiator ports are referred to as 
buses. A SCSI target device that has SCSI devices attached to these buses shall assign numbers, other than zero, 
to those buses. The bus numbers shall be used as components of the logical unit numbers to the logical units 
attached to those buses, as described in 4.9.6 and 4.9.8. 

SCSI target devices shall assign a bus number of zero to all the logical units under control by the SCSI target 
device that are not connected through a SCSI domain where the SCSI target device functions as a SCSI initiator 
device. 
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4.15 The SCSI model for distributed communications 

The SCSI model for communications between distributed objects is based on the technique of layering as shown in 
figure 25. 
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Figure 25 — Protocol service reference model 


The layers comprising this model and the specifications defining the functionality of each layer are denoted by 
horizontal sequences. A layer consists of peer entities that communicate with one another by means of a protocol. 
Except for the interconnect layer, such communication is accomplished by invoking services provided by the 
adjacent layer. The following layers are defined. 

SCSI application layer (SAL): Contains the clients and servers that originate and process SCSI I/O opera¬ 
tions by means of a SCSI application protocol. 

SCSI transport protocol layer (STPL): Consists of the services and protocols through which clients and 
servers communicate. 

Interconnect layer: Comprised of the services, signaling mechanism and interconnect subsystem used for the 
physical transfer of data from sender to receiver. In the SCSI model, the interconnect layer is known as the 
service delivery subsystem. 

The set of SCSI transport protocol services implemented by the service delivery subsystem identify external 
behavioral requirements that apply to SCSI transport protocol standards. While these SCSI transport protocol 
services may serve as a guide for designing reusable software or firmware that is adaptable to different SCSI 
transport protocols, there is no requirement for an implementation to provide the service interfaces specified in this 
standard. 

The SCSI transport protocol service interface is defined in this standard in representational terms using SCSI 
transport protocol services. The SCSI transport protocol service interface implementation is defined in each SCSI 
transport protocol standard. The interconnect service interface is described as appropriate in each SCSI transport 
protocol standard. 
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Interactions between the SAL and STPL are defined with respect to the SAL and may originate in either layer. An 
outgoing interaction is modeled as a procedure call invoking an STPL service. An incoming interaction is modeled 
as a procedure call invoked by the STPL. 

All procedure calls may be accompanied by parameters or data. Both types of interaction are described using the 
notation for procedures specified in 3.6.2. In this standard, input arguments are defined relative to the layer 
receiving an interaction (i.e., an input is a argument supplied to the receiving layer by the layer initiating the inter¬ 
action). 

The following types of service interactions between layers are defined: 

a) SCSI transport protocol service request procedure calls from the SAL invoking a service provided by the 
STPL; 

b) SCSI transport protocol service indication procedure calls from the STPL informing the SAL that an 
asynchronous event has occurred (e.g., the receipt of a peer-to-peer protocol transaction); 

c) SCSI transport protocol service response procedure calls to the STPL invoked by the SAL in response to a 
SCSI transport protocol service indication. A SCSI transport protocol service response may be invoked to 
return a reply from the invoking SAL to the peer SAL; and 

d) SCSI transport protocol service confirmation procedure calls from the STPL notifying the SAL that a SCSI 
transport protocol service request has completed, has been terminated, or has failed to transit the inter¬ 
connect layer. A confirmation may communicate parameters that indicate the completion status of the 
SCSI transport protocol service request or any other status. A SCSI transport protocol service confirmation 
may be used to convey a response from the peer SAL. 

The services provided by an STPL are either confirmed or unconfirmed. A SAL service request invoking a 
confirmed service always results in a confirmation from the STPL. 

Figure 26 shows the relationships between the four SCSI transport protocol service types. 



Figure 26 — SCSI transport protocol service model 


dpANS SCSI Architecture Model - 3 (SAM-3) 


54 




T10/1561-D revision 14 


21 September 2004 


Figure 27 shows how SCSI transport protocol services may be used to process a client-server request-response 
transaction at the SCSI application layer. 



Service Interface 


Figure 27 — Request-Response SAL transaction and related STPL services 


The dashed lines in figure 27 show a SCSI application protocol transaction as it may appear to sending and 
receiving entities within the client and server. The solid lines in figure 27 show the corresponding SCSI transport 
protocol services and STPL transactions that are used to transport the data. 
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When a device server invokes a data transfer SCSI transport protocol service, the interactions required to transfer 
the data do not involve the application client. Only the STPL in the SCSI device that also contains the application 
client is involved. Figure 28 shows the relationships between the SCSI transport protocol service types involved in 
a data transfer request. 



Figure 28 — SCSI transport protocol service model for data transfers 

Figure 29 shows how SCSI transport protocol services may be used to process a device server data transfer trans¬ 
action. 
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Note: The dotted box represents a memory access function provided by the SCSI 
initiator device whose definition is outside the scope of this standard. 


Figure 29 — Device server data transfer transaction and related STPL services 
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When a device server invokes a Terminate Data Transfer SCSI transport protocol service, the interactions required 
to complete the service do not involve the SCSI Transport Protocol Service Interface or the application client. Only 
the STPL in the SCSI device that also contains the device server is involved. Figure 30 shows the relationships 
between the SCSI transport protocol service types involved in a Terminate Data Transfer request. 


SAL 

f 

| STPL 

T 


T 


SCSI Transport 
Protocol Service 
Request 





SCSI Transport 
Protocol Service 
Confirmation 



Figure 30 — SCSI transport protocol service model for Terminate Data Transfer 


Figure 31 shows how SCSI transport protocol services may be used to process a device server Terminate Data 
Transfer transaction. 
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Figure 31 — Device server Terminate Data Transfer transaction and related STPL services 
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5 SCSI command model 

5.1 The Execute Command procedure call 

An application client requests the processing of a command by invoking the SCSI transport protocol services 
described in 5.4, the collective operation of which is modeled in the following procedure call: 

Service Response = Execute Command (IN (l_T_L_Q Nexus, CDB, Task Attribute, [Data-In Buffer Size], 
[Data-Out Buffer], [Data-Out Buffer Size], [Command Reference Number], [Task 
Priority]), OUT ([Data-In Buffer], [Sense Data], [Sense Data Length], Status )) 

Input Arguments: 

l_T_L_Q Nexus: The l_T_L_Q nexus identifying the task (see 4.12). 

CDB: Command descriptor block (see 5.2). 

Task Attribute: A value specifying one of the task attributes defined in 8.6. SCSI transport proto¬ 
cols may or may not provide the ability to specify a different task attribute for 
each task (see 8.6.1). For a task that processes linked commands, the Task 
Attribute shall be the value specified for the first command in a series of linked 
commands. The Task Attribute specified for the second and subsequent com¬ 
mands shall be ignored. 

Data-In Buffer Size: The number of bytes available for data transfers to the Data-In Buffer (see 5.4.3). 

SCSI transport protocols may interpret this argument to include both the size 
and the location of the Data-In Buffer. 

Data-Out Buffer: A buffer containing command specific information to be sent to the logical unit 
(e.g., data or parameter lists needed to process the command). The buffer size 
is indicated by the Data-Out Buffer Size argument. The content of the Data-Out 
Buffer shall not change during the lifetime of the command (see 5.5) as viewed 
by the application client. 

Data-Out Buffer Size: The number of bytes available for data transfers from the Data-Out Buffer (see 
5.4.3). 

Command Reference When this argument is used, all sequential commands of an l_T_L nexus shall 
Number (CRN): include a CRN argument that is incremented by one. The CRN shall be set to 
one for each l_T_L nexus involving the SCSI port after the SCSI port receives a 
hard reset or detects l_T nexus loss. The CRN shall be set to one after it 
reaches the maximum CRN value supported by the protocol. The CRN value 
zero shall be reserved for use as defined by the SCSI transport protocol. It is not 
an error for the application client to provide this argument when CRN is not 
supported by the SCSI transport protocol or logical unit. 

Task Priority: The priority assigned to the task (see 8.7). 
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Output Arguments: 

Data-In Buffer: A buffer to contain command specific information returned by the logical unit by 
the time of command completion. The Execute Command procedure call shall 
not return a status of GOOD, CONDITION MET, INTERMEDIATE, or INTERME¬ 
DIATE-CONDITION MET unless the buffer contents are valid. The application 
client shall treat the buffer contents as invalid unless the command completes 
with a status of GOOD, CONDITION MET, INTERMEDIATE, or INTERMEDI¬ 
ATE-CONDITION MET. While some valid data may be present for other values 
of status, the application client should rely on additional information from the log¬ 
ical unit (e.g., sense data) to determine the state of the buffer contents. If the 
command ends with a service response of service delivery or target fail¬ 
ure, the application client shall consider this argument to be undefined. 

Sense Data: A buffer containing sense data returned in the same l_T_L_Q nexus transaction 
(see 3.1.47) as a CHECK CONDITION status (see 5.9.6). The buffer length is 
indicated by the Sense Data Length argument. If the command ends with a ser¬ 
vice response of service delivery or target failure, the application client 
shall consider this argument to be undefined. 

Sense Data Length: The length in bytes of the Sense Data. 

Status: A one-byte field containing command completion status (see 5.3). If the com¬ 
mand ends with a service response of service delivery or target failure, the 
application client shall consider this argument to be undefined. 

Service Response assumes one of the following values: 

task complete: A logical unit response indicating that the task has ended. The Status argument 
shall have one of the values specified in 5.3 other than INTERMEDIATE or 
INTERMEDIATE-CONDITION MET. 

linked command Logical unit responses indicating that the task has not ended and that a linked 
complete: command has completed successfully. As specified in 5.3, the Status argument 
shall have a value of INTERMEDIATE or INTERMEDIATE-CONDITION MET. 
service delivery or The command has been ended due to a service delivery failure (see 3.1.112) or 
target failure: SCSI target device malfunction. All output parameters are invalid. 

The SCSI transport protocol events corresponding to a response of task complete, linked command complete or 
service delivery or target failure shall be specified in each SCSI transport protocol standard. 

An application client requests processing of a linked command by setting the link bit to one in the CDB control 
byte as specified in 5.2. The task attribute and task priority are determined by the Task Attribute argument and the 
Task Priority argument, respectively, specified for the first command in the series of linked commands. Upon 
receiving a response of linked command complete, an application client may issue the next command in the series 
through an Execute Command procedure call having the same l_T_L_Q nexus and omitting the Task Attribute 
argument. If the logical unit receives the next command in a series of linked commands before completing the 
current command in that linked command series, the overlapped command condition described in 5.9.3 shall 
result. 
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5.2 Command descriptor block (CDB) 

The CDB defines the operation to be performed by the device server. 

For all commands, if the logical unit detects an invalid parameter in the CDB, then the logical unit shall not process 
the command. 

All CDBs shall have an operation code as the first byte. 

Some operation codes provide for modification of their operation based on a service action. In such cases, the 
combination of operation code value and service action code value may be modeled as a single, unique command 
determinate. The location of the service action field in the CDB varies depending on the operation code value. 

All CDBs shall contain a control byte (see table 21). The location of the control byte within a CDB depends on 
the CDB format (see SPC-3). 


Table 21 — control byte 


Bit 

7 | 6 

5 | 4 | 3 

2 

1 

0 


Vendor specific 

Reserved 

NACA 

Obsolete 

LINK 


All SCSI transport protocol standards shall define as mandatory the functionality needed for a logical unit to 
implement the naca bit and link bit. 

The naca (Normal ACA) bit specifies whether an auto contingent allegiance (ACA) is established if the command 
returns with CHECK CONDITION status. An naca bit set to one specifies that an ACA shall be established. An 
naca bit set to zero specifies that an ACA shall not be established. The actions for ACA are specified in 5.9.2. 
Actions that may be required when an ACA is not established are described in 5.9.1. All logical units shall 
implement support for the naca value of zero and may support the naca value of one (i.e., ACA). The ability to 
support a naca value of one is indicated with the NormACA bit in the standard INQUIRY data (see SPC-3). 

If the naca bit is set to one but the logical unit does not support ACA, the command shall be terminated with 
CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST, and the additional sense code set to 
INVALID FIELD IN CDB. 

The link bit is used to continue the task across multiple commands. Support for the link bit is optional. The appli¬ 
cation client sets the link bit to one to specify a request for continuation of the task across two or more commands. 
If the link bit is set to one and the command completes successfully, a logical unit that supports the link bit shall 
continue the task and return a status of INTERMEDIATE or INTERMEDIATE-CONDITION MET and a service 
response of linked command complete (see 5.3). If the link bit is set to one and the logical unit does not support 
linked commands, the command shall be terminated with CHECK CONDITION status, with the sense key set to 
ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD IN CDB. 
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5.3 Status 

5.3.1 Status codes 

The status codes are specified in table 22. Status shall be sent from the device server to the application client 
whenever a command ends with a service response of task complete or linked command complete. 


Table 22 — Status codes 


Status Code 

Status 

Task Ended 

Service Response 

OOh 

GOOD 

Yes 

TASK COMPLETE 

02 h 

CHECK CONDITION 

Yes 

TASK COMPLETE 

04h 

CONDITION MET 

Yes 

TASK COMPLETE 

08h 

BUSY 

Yes 

TASK COMPLETE 

lOh 

INTERMEDIATE 

No 

LINKED COMMAND COMPLETE 

14h 

INTERMEDIATE-CONDITION MET 

No 

LINKED COMMAND COMPLETE 

18h 

RESERVATION CONFLICT 

Yes 

TASK COMPLETE 

22h 

Obsolete 



28h 

TASK SET FULL 

Yes 

TASK COMPLETE 

30h 

ACA ACTIVE 

Yes 

TASK COMPLETE 

40h 

TASK ABORTED 

Yes 

TASK COMPLETE 

All other codes 

Reserved 




Definitions for each status code are as follows: 

GOOD. This status indicates that the device server has successfully completed the task. 

CHECK CONDITION. This status indicates that sense data has been delivered in the buffer defined by the Sense 
Data argument to the Execute Command procedure call (see 5.9.6). Additional actions that are required when 
CHECK CONDITION status is returned are described in 5.9.1. 

CONDITION MET. The use of this status is limited to commands for which it is specified (see the PRE-FETCH 
commands in the SBC-2 standard). 

BUSY. This status indicates that the logical unit is busy. This status shall be returned whenever a logical unit is 
temporarily unable to accept a command. The recommended application client recovery action is to issue the 
command again at a later time. 

If the ua_intlck_ctrl field in the Control mode page contains 11b (see SPC-3), termination of a command with 
BUSY status shall cause a unit attention condition to be established for the SCSI initiator port that sent the 
command with an additional sense code set to PREVIOUS BUSY STATUS unless a PREVIOUS BUSY STATUS 
unit attention condition already exists. 

INTERMEDIATE. This status or INTERMEDIATE-CONDITION MET shall be returned for each successfully 
completed command in a series of linked commands (except the last command), unless the command is termi¬ 
nated with CHECK CONDITION, RESERVATION CONFLICT, TASK SET FULL, or BUSY status. If INTERME¬ 
DIATE or INTERMEDIATE-CONDITION MET status is not returned, the series of linked commands is terminated 
and the task is ended. This status is the equivalent of GOOD status for linked commands. 
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INTERMEDIATE-CONDITION MET. The use of this status is limited to commands for which it is specified (see the 
PRE-FETCH commands in the SBC-2 standard), unless the command is terminated with CHECK CONDITION, 
RESERVATION CONFLICT, TASK SET FULL, or BUSY status. If INTERMEDIATE or INTERME¬ 
DIATE-CONDITION MET status is not returned, the series of linked commands is terminated and the task is 
ended. 

RESERVATION CONFLICT. This status shall be returned whenever a command attempts to access a logical unit 
in a way that conflicts with an existing reservation. (See the PERSISTENT RESERVE OUT command and 
PERSISTENT RESERVE IN command in SPC-3.) 

If the ua_intlck_ctrl field in the Control mode page contains 11b (see SPC-3), termination of a command with 
RESERVATION CONFLICT status shall cause a unit attention condition to be established for the SCSI initiator port 
that sent the command with an additional sense code set to PREVIOUS RESERVATION CONFLICT STATUS 
unless a PREVIOUS RESERVATION CONFLICT STATUS unit attention condition already exists. 

TASK SET FULL. When the logical unit has at least one task in the task set for a SCSI initiator port and a lack of 
task set resources prevents accepting a received task from that SCSI initiator port into the task set, TASK SET 
FULL shall be returned. When the logical unit has no task in the task set for a SCSI initiator port and a lack of task 
set resources prevents accepting a received task from that SCSI initiator port into the task set, BUSY should be 
returned. 

The logical unit should allow at least one command in the task set for each supported SCSI initiator port that has 
identified itself to the SCSI target port in a SCSI transport protocol specific manner or by the successful trans¬ 
mission of a command. 

If the ua_intlck_ctrl field in the Control mode page contains 11b (see SPC-3), termination of a command with 
TASK SET FULL status shall cause a unit attention condition to be established for the SCSI initiator port that sent 
the command with an additional sense code set to PREVIOUS TASK SET FULL STATUS unless a PREVIOUS 
TASK SET FULL STATUS unit attention condition already exists. 

ACA ACTIVE. This status shall be returned as described in 5.9.2.2 and 5.9.2.3 when an ACA exists within a task 
set. The SCSI initiator port may reissue the command after the ACA condition has been cleared. 

TASK ABORTED. This status shall be returned when a task is aborted by another SCSI initiator port and the 
Control mode page tas bit is set to one (see 5.7.3). 
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5.3.2 Status precedence 

If a device server detects that more than one of the following conditions applies to a completed task, it shall select 
the condition to report based on the following precedence: 

1) An ACA ACTIVE status; 

2) A CHECK CONDITION status for any of the following unit attention conditions (i.e., with a sense key set to 
UNIT ATTENTION and one of the following additional sense codes): 

A) POWER ON, RESET, OR BUS DEVICE RESET OCCURRED; 

B) POWER ON OCCURRED; 

C) SCSI BUS RESET OCCURRED; 

D) BUS DEVICE RESET FUNCTION OCCURRED; 

E) DEVICE INTERNAL RESET; or 

F) l_T NEXUS LOSS OCCURRED; 

3) A RESERVATION CONFLICT status; 
and 

4) A status of: 

A) CHECK CONDITION, for any reason not listed in 2); 

B) GOOD; 

C) CONDITION MET; 

D) INTERMEDIATE; 

E) INTERMEDIATE-CONDITION MET; or 

F) TASK ABORTED. 


NOTE 5 - The names of the unit attention conditions listed in the subclause (e.g., SCSI BUS RESET OCCURRED) 
are based on usage in previous versions of this standard. The use of these unit attention condition names is not to 
be interpreted as a description of how the unit attention conditions are represented by any given SCSI transport 
protocol. 

A device server may report the following status codes with any level of precedence: 

a) BUSY status; 

b) TASK SET FULL status; or 

c) CHECK CONDITION status with a sense key set to ILLEGAL REQUEST. 
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5.4 SCSI transport protocol services in support of Execute Command 

5.4.1 Overview 

The SCSI transport protocol services that support the Execute Command procedure call are described in 5.4. 
Two groups of SCSI transport protocol services are described. The SCSI transport protocol services that support 
the request and confirmation for the Execute Command procedure call are described in 5.4.2. The SCSI transport 
protocol services that support the data transfers associated with processing a command are described in 5.4.3. 

5.4.2 Execute Command request/confirmation SCSI transport protocol services 

All SCSI transport protocol standards shall define the SCSI transport protocol specific requirements for imple¬ 
menting the Send SCSI Command request, the SCSI Command Received indication, the Send Command 
Complete response, and the Command Complete Received confirmation SCSI transport protocol services. 

All SCSI initiator devices shall implement the Send SCSI Command request and the Command Complete 
Received confirmation SCSI transport protocol services as defined in the applicable SCSI transport protocol 
standards. All SCSI target devices shall implement the SCSI Command Received indication and the Send 
Command Complete response SCSI transport protocol services as defined in the applicable SCSI transport 
protocol standards. 

SCSI Transport Protocol Service Request: 

Send SCSI Command (IN (l_T_L_Q Nexus, CDB, Task Attribute, [Data-In Buffer Size], 

[Data-Out Buffer], [Data-Out Buffer Size], [Command Reference Number], 
[Task Priority], [First Burst Enabled])) 

Input Arguments: 

l_T_L_Q Nexus: The l_T_L_Q nexus identifying the task (see 4.12). 

CDB: Command descriptor block (see 5.2). 

Task Attribute: A value specifying one of the task attributes defined in 8.6. For specific require¬ 
ments on the Task Attribute argument see 5.1. 

Data-In Buffer Size: The number of bytes available for data transfers to the Data-In Buffer (see 5.4.3). 

SCSI transport protocols may interpret this argument to include both the size 
and the location of the Data-In Buffer. 

Data-Out Buffer: A buffer containing command specific information to be sent to the logical unit 
(e.g., data or parameter lists needed to process the command (see 5.1)). The 
content of the Data-Out Buffer shall not change during the lifetime of the 
command (see 5.5) as viewed by the application client. 

Data-Out Buffer Size: The number of bytes available for data transfers from the Data-Out Buffer (see 
5.4.3). 

Command Reference When this argument is used, all sequential commands of an l_T_L nexus shall 

Number (CRN): include a CRN argument that is incremented by one (see 5.1). 

Task Priority: The priority assigned to the task (see 8.7). 

First Burst Enabled: An argument specifying that a SCSI transport protocol specific number of bytes 
from the Data-Out Buffer shall be delivered to the logical unit without waiting for 
the device server to invoke the Receive Data-Out SCSI transport protocol 
service. 
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SCSI Transport Protocol Service Indication: 

SCSI Command Received (IN (l_T_L_Q Nexus, CDB, Task Attribute, [Command Reference Number], 
[Task Priority], [First Burst Enabled])) 

Input Arguments: 

l_T_L_Q Nexus: The l_T_L_Q nexus identifying the task (see 4.12). 

CDB: Command descriptor block (see 5.2). 

Task Attribute: A value specifying one of the task attributes defined in 8.6. For specific require¬ 
ments on the Task Attribute argument see 5.1. 

Command Reference When this argument is used, all sequential commands of an l_T_L nexus shall 

Number (CRN): include a CRN argument that is incremented by one (see 5.1). 

Task Priority: The priority assigned to the task (see 8.7). 

First Burst Enabled: An argument specifying that a SCSI transport protocol specific number of bytes 
from the Data-Out Buffer are being delivered to the logical unit without waiting 
for the device server to invoke the Receive Data-Out SCSI transport protocol 
service. 

SCSI Transport Protocol Service Response (from device server): 

Send Command Complete (IN (l_T_L_Q Nexus, [Sense Data], [Sense Data Length], Status, 

Service Response)) 

Input Arguments: 

l_T_L_Q Nexus: The l_T_L_Q nexus identifying the task (see 4.12). 

Sense Data: If present, this argument instructs the SCSI target port to return sense data to 
the SCSI initiator port (see 5.9.6). 

Sense Data Length: The length in bytes of the sense data to be returned to the SCSI initiator port. 

Status: Command completion status (see 5.1). 

Service Response: Possible service response information for the command (see 5.1). 

SCSI Transport Protocol Service Confirmation: 

Command Complete Received (IN (l_T_L_Q Nexus, [Data-In Buffer], [Sense Data], [Sense Data Length], 
Status, Service Response)) 

Input Arguments: 

l_T_L_Q Nexus: The l_T_L_Q nexus identifying the task (see 4.12). 

Data-In Buffer: A buffer containing command specific information returned by the logical unit on 
command completion (see 5.1). 

Sense Data: Sense data returned in the same l_T_L_Q nexus transaction (see 3.1.47) as a 
CHECK CONDITION status (see 5.9.6). 

Sense Data Length: The length in bytes of the received sense data. 

Status: Command completion status (see 5.1). 

Service Response: Service response for the command (see 5.1). 
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5.4.3 Data transfer SCSI transport protocol services 
5.4.3.1 Introduction 

The data transfer services described in 5.4.3 provide mechanisms for moving data to and from the SCSI initiator 
port in response to commands transmitted using the Execute Command procedure call. All SCSI transport 
protocol standards shall define the protocols required to implement these services. 

The application client's Data-In Buffer and/or Data-Out Buffer each appears to the device server as a single, 
logically contiguous block of memory large enough to hold all the data required by the command (see figure 32). 
This standard allows either unidirectional or bidirectional data transfer. The processing of a command may require 
the transfer of data from the application client using the Data-Out Buffer, or to the application client using the 
Data-In Buffer, or both to and from the application client using both the Data-In Buffer and the Data-Out Buffer. 



This standard assumes that the buffering resources available to the logical unit are limited and may be less than 
the amount of data that is capable of being transferred in one command. Such data needs to be moved between 
the application client and the media in segments that are smaller than the transfer size specified in the command. 
The amount of data moved per segment is usually a function of the buffering resources available to the logical unit. 
Figure 32 shows the model for such incremental data transfers. 

SCSI transport protocols may allow logical units to accept the initial portion of the Data-Out Buffer data, called the 
first burst, along with the command without waiting for the device server to invoke the Receive Data-Out SCSI 
transport protocol service. This is modeled using Receive Data-Out protocol service calls for which the SCSI 
transport protocol may have moved the first burst prior to the call. 

SCSI transport protocols that define a first burst capability shall include the First Burst Enabled argument in their 
definitions for the Send SCSI Command and SCSI Command Received procedure calls. Logical units that 
implement the first burst capability shall implement the first burst size field in the Disconnect-Reconnect mode 
page (see SPC-3). 
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The movement of data between the application client and device server is controlled by the following arguments: 


Application Client 
Buffer Size: 


The total number of bytes in the application client's buffer (i.e., equivalent to 
Data-In Buffer Size for the Data-In Buffer or equivalent to Data-Out Buffer Size 
for the Data-Out Buffer). 


Application Client 
Buffer Offset: 


Offset in bytes from the beginning of the application client's buffer (Data-In or 
Data-Out) to the first byte of transferred data. 


Byte Count Requested Number of bytes to be moved by the data transfer request. 

by Device Server: 


For any specific data transfer SCSI transport protocol service request, the Byte Count Requested by Device 
Server is less than or equal to the combination of Application Client Buffer Size minus the Application Client 
Buffer Offset. 


If a SCSI transport protocol supports random buffer access, the offset and byte count specified for each data 
segment to be transferred may overlap. In this case the total number of bytes moved for a command is not a 
reliable indicator of highest byte transferred and shall not be used by a SCSI initiator device or SCSI target device 
implementation to determine whether all data has been transferred. 

All SCSI transport protocol standards shall define support for a resolution of one byte for the Application Client 
Buffer Size argument. 

SCSI transport protocol standards may define restrictions on the resolution of the Application Client Buffer Offset 
argument. SCSI transport protocol standards may define restrictions on the resolution of the Request Byte Count 
argument for any call to Send Data-In or any call to Receive Data-Out that does not transfer the last byte of the 
Application Client Buffer. 

Random buffer access occurs when the device server requests data transfers to or from segments of the appli¬ 
cation client's buffer that have an arbitrary offset and byte count. Buffer access is sequential when successive 
transfers access a series of increasing, adjoining buffer segments. Support for random buffer access by a SCSI 
transport protocol standard is optional. A device server implementation designed for any SCSI transport protocol 
implementation should be prepared to use sequential buffer access when necessary. 

The STPL confirmed services specified in 5.4.3.2 and 5.4.3.3 are used by the device server to request the transfer 
of data to or from the application client Data-In Buffer or Data-Out Buffer, respectively. The SCSI initiator device 
SCSI transport protocol service interactions are unspecified. 

This standard provides only for the transfer phases to be sequential. Provision for overlapping transfer phases is 
outside the scope of this standard. 
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5.4.3.2 Data-In delivery service 
Request: 

Send Data-In (IN (l_T_L_Q Nexus, Device Server Buffer, Application Client Buffer Offset, 
Request Byte Count)) 


Argument descriptions: 


l_T_L_Q Nexus: 
Device Server Buffer: 
Application Client 
Buffer Offset: 
Request Byte Count: 


The l_T_L_Q nexus identifying the task (see 4.12). 

The buffer in the device server from which data is to be transferred. 

Offset in bytes from the beginning of the application client's buffer (i.e., the 
Data-In Buffer) to the first byte of transferred data. 

Number of bytes to be moved by this request. 


Confirmation: 


Data-In Delivered (IN (l_T_L_Q Nexus, Delivery Result)) 

This confirmation notifies the device server that the specified data was successfully delivered to the application 
client buffer, or that a service delivery subsystem error occurred while attempting to deliver the data. 

Argument descriptions: 


l_T_L_Q Nexus: The l_T_L_Q nexus identifying the task (see 4.12). 

Delivery Result: an encoded value representing one of the following: 

delivery successful: The data was delivered successfully. 

delivery failure: A service delivery subsystem error occurred while 
attempting to deliver the data. 


5.4.3.3 Data-Out delivery service 
Request: 

Receive Data-Out (IN (l_T_L_Q Nexus, Application Client Buffer Offset, Request Byte Count, 
Device Server Buffer)) 


Argument descriptions: 


l_T_L_Q Nexus: 
Device Server Buffer: 
Application Client 
Buffer Offset: 
Request Byte Count: 


The l_T_L_Q nexus identifying the task (see 4.12). 

The buffer in the device server to which data is to be transferred. 

Offset in bytes from the beginning of the application client's buffer (i.e., the 
Data-Out Buffer) to the first byte of transferred data. 

Number of bytes to be moved by this request. 


If the SCSI Command Received SCSI transport protocol service included a First Burst Enabled argument and 
random buffer access is not supported, first burst data shall be transferred to the Device Server Buffer until all first 
burst data has been transferred. If the SCSI Command Received SCSI transport protocol service included a First 
Burst Enabled argument and random buffer access is supported, first burst data should be transferred to the 
Device Server Buffer but first burst data may be re-transferred across the service delivery subsystem. 


dpANS SCSI Architecture Model - 3 (SAM-3) 



T10/1561-D revision 14 


21 September 2004 


Confirmation: 

Data-Out Received (IN (l_T_L_Q Nexus, Delivery Result)) 

This confirmation notifies the device server that the requested data has been successfully delivered to its buffer, or 
that a service delivery subsystem error occurred while attempting to receive the data. 

Argument descriptions: 

l_T_L_Q Nexus: The l_T_L_Q nexus identifying the task (see 4.12). 

Delivery Result: an encoded value representing one of the following: 

delivery successful: The data was delivered successfully. 

delivery failure: A service delivery subsystem error occurred while 
attempting to receive the data. 


5.4.3.4 Terminate Data Transfer service 

The terminate data transfer request and confirmation may be used by a task manager to terminate partially 
completed transfers to the Data-In Buffer or from the Data-Out Buffer. 

The Terminate Data Transfer SCSI transport protocol service allows a device server to specify that one or more 
Send Data-In or Receive Data-Out SCSI transport protocol service requests be terminated by a SCSI target port. 

Request: 

Terminate Data Transfer (IN ( Nexus )) 

Argument description: 


Nexus: An l_T Nexus, l_T_L Nexus, or l_T_L_G Nexus (see 4.12). 

The SCSI target port terminates all transfer service requests for the specified nexus (e.g., if an l_T_L nexus is 
specified, then the SCSI target port terminates all transfer service requests from the logical unit for the specified 
SCSI initiator port). 

Confirmation: 

Data Transfer Terminated (IN ( Nexus )) 

Argument description: 


Nexus: An l_T Nexus, l_T_L Nexus, or l_T_L_G Nexus (see 4.12). 

This confirmation is returned in response to a Terminate Data Transfer request whether or not the specified nexus 
existed in the SCSI target port when the request was received. After a Data Transfer Terminated SCSI transport 
protocol service confirmation has been sent in response to a Terminate Data Transfer SCSI transport protocol 
service request, Data-In Delivered or Data-Out Received SCSI transport protocol service confirmations shall not 
be sent for the tasks specified by the nexus. 
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5.5 Task and command lifetimes 

This subclause specifies the events delimiting the beginning and end (i.e., lifetime) of a task or pending command 
from the viewpoint of the device server and application client. 

The device server shall create a task upon receiving a SCSI Command Received indication unless the command 
represents a continuation of a linked command as described in 5.1. 

The task shall exist until: 

a) The device server sends a SCSI transport protocol service response for the task of task complete; or 

b) The task is aborted as described in 5.7. 

The application client maintains an application client task to interact with the task from the time the Send SCSI 
Command SCSI transport protocol service request is invoked until it receives one of the following SCSI target 
device responses: 

a) A service response of task complete for that task; 

b) Notification of a unit attention condition with one of the following additional sense codes; 

A) COMMANDS CLEARED BY ANOTHER INITIATOR, if in reference to the task set containing the task; 

B) Any additional sense code whose additional sense code field contains 29h (e.g., POWER ON, 
RESET, OR BUS DEVICE RESET OCCURRED; POWER ON OCCURRED; SCSI BUS RESET 
OCCURRED; BUS DEVICE RESET FUNCTION OCCURRED; DEVICE INTERNAL RESET; or l_T 
NEXUS LOSS OCCURRED); 

c) Notification that the task manager has detected the use of a duplicate l_T_L_Q nexus (see 5.9.3); 

d) A service response of function complete following an ABORT TASK task management function directed 
to the specified task; 

e) A service response of function complete following an ABORT TASK SET or a CLEAR TASK SET task 
management function directed to the task set containing the specified task; or 

f) A service response of function complete in response to a LOGICAL UNIT RESET task management 
function directed to the logical unit. 

If a service response of service delivery or target failure is received for a command, the application client 
shall maintain an application client task to interact with the task until the application client has determined (e.g., by 
completion of an ABORT TASK task management function) that the task is no longer known to the device server. 

NOTE 6 - The names of the unit attention conditions listed in the subclause (e.g., SCSI BUS RESET OCCURRED) 
are based on usage in previous versions of this standard. The use of these unit attention condition names is not to 
be interpreted as a description of how the unit attention conditions are represented by any given SCSI transport 
protocol. 

To the application client, the command is pending from the time it calls the Send SCSI Command SCSI transport 
protocol service until one of the responses described in this subclause or a service response of linked command 
complete is received. 

When a SCSI transport protocol does not require state synchronization (see 4.6.2), there may be a time skew 
between the completion of a device server request-response transaction as seen by the application client and 
device server. As a result, the lifetime of a task or command as it appears to the application client is different from 
the lifetime observed by the device server. 

Some commands (e.g., commands with immediate bits like SEND DIAGNOSTIC, or write commands when a write 
cache is enabled) start background operations that operate after the task containing the command is no longer in 
the task set. Background operations may be aborted by power on, hard resets, or logical unit resets. Background 
operations shall not be aborted by l_T nexus loss. 
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Background operations may generate deferred errors that are reported in the sense data for a subsequent 
completed command (see SPC-3). Information that a deferred error occurred may be cleared before it is reported 
(e.g., by power on, hard reset, or logical unit reset). Deferred errors should not be cleared by l_T nexus loss. 

Unless a command completes with a GOOD, CONDITION MET, INTERMEDIATE, or INTERME¬ 
DIATE-CONDITION MET status the degree to which the required command processing has been completed is 
vendor specific. 


5.6 Task management function lifetime 

The application client assumes that the task management function is in process from the time the Send Task 
Management Request SCSI transport protocol service request is invoked until it receives one of the following 
SCSI target device responses: 

a) A service response of function complete, function succeeded, function rejected, or service 
delivery or target failure is received for that task management function; or 

b) Notification of a unit attention condition with any additional sense code whose additional sense code field 
contains 29h (e.g., POWER ON, RESET, OR BUS DEVICE RESET OCCURRED; POWER ON 
OCCURRED; SCSI BUS RESET OCCURRED; BUS DEVICE RESET FUNCTION OCCURRED; DEVICE 
INTERNAL RESET). 

NOTE 7 - The names of the unit attention conditions listed in the subclause (e.g., SCSI BUS RESET OCCURRED) 
are based on usage in previous versions of this standard. The use of these unit attention condition names is not to 
be interpreted as a description of how the unit attention conditions are represented by any given SCSI transport 
protocol. 


5.7 Aborting tasks 

5.7.1 Mechanisms that cause tasks to be aborted 

A task is aborted when an event or SCSI initiator device action causes termination of the task prior to its successful 
completion. 

The following events cause a task or several tasks to be aborted: 

a) The return of an Execute Command service response of service delivery or target failure as 
described in 5.1; 

b) An l_T nexus loss (see 6.3.4); 

c) A logical unit reset (see 6.3.3); 

d) A hard reset (see 6.3.2); or 

e) A power on condition (see 6.3.1). 

An action transmitted via one l_T nexus may abort task(s) received on that l_T nexus and/or task(s) received on 
other l_T nexuses. 

The following actions affect only the task(s) received on the l_T nexus on which the action is transmitted: 

a) Completion of an ABORT TASK task management function directed to the specified task; 

b) Completion of an ABORT TASK SET task management function under the conditions specified in 7.3; or 
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c) Completion of a command with a CHECK CONDITION status, without establishing an ACA condition (see 
5.9.1.3) or establishing an ACA condition (see 5.9.2.2), while the Control mode page (see SPC-3) contains 
fields that are set as follows: 

A) The QErr field set to 01 b and the tst field set to 001 b; or 

B) The QErr field set to 11b. 

The actions shown in table 23 affect the task(s) received on the l_T nexus on which the action is transmitted and/or 
task(s) received on other l_T nexuses. 


Table 23 — Actions that affect task(s) received on this or other l_T nexuses 


Action 

Unit attention additional 
sense code, if any (see 5.7.3) 

Completion of a CLEAR TASK SET task management function referencing the 
task set containing the specified task 

COMMANDS CLEARED BY 
ANOTHER INITIATOR 

Completion of a command with a CHECK CONDITION status, with or without 
establishing an ACA condition, and the QErr field was set to 01b and the tst 
field was set to 000b in the Control mode page (see SPC-3) 

COMMANDS CLEARED BY 
ANOTHER INITIATOR 

Completion of a PERSISTENT RESERVE OUT command with a PREEMPT 
AND ABORT service action with a reservation key that is associated with the 
l_T nexus on which the task was received (see SPC-3) 

COMMANDS CLEARED BY 
ANOTHER INITIATOR 

Completion of a LOGICAL UNIT RESET task management function (see 7.6) 
directed to the logical unit 

BUS DEVICE RESET 
FUNCTION OCCURRED 


If one or more tasks are cleared or aborted, the affected tasks are also cleared from the initiator ports in a manner 
that is outside the scope of this standard. 

5.7.2 When a SCSI initiator port aborts tasks received on its own l_T nexus 

When a SCSI initiator port causes task(s) received on its own l_T nexus to be aborted, no notification that the 
task(s) have been aborted shall be returned to the SCSI initiator port other than the completion response for the 
command or task management function action that caused the task(s) to be aborted and notification(s) associated 
with related effects of the action (e.g., a reset unit attention condition). 

5.7.3 When a SCSI initiator port aborts tasks received on other l_T nexuses 

When a SCSI initiator port causes task(s) received on other l_T nexus(es) to be aborted, the SCSI initiator port 
associated with every other l_T nexus shall be notified that the task(s) have been aborted. The method of notifi¬ 
cation shall depend on the setting of the tas bit in the Control mode page (see SPC-3) that applies to the SCSI 
initiator port(s) associated with the other l_T nexus(es). 

If the tas bit is set to zero, the method of notification shall be a unit attention condition. The additional sense code 
for the unit attention condition depends on the action that caused the task(s) to be aborted as described in table 23 
(see 5.7.1). 

If the tas bit is set to one, the method of notification shall be the termination of each aborted task with a TASK 
ABORTED status. The COMMANDS CLEARED BY ANOTHER INITIATOR unit attention condition shall not be 
established, however, the establishment of any other applicable unit attention condition shall not be affected. 

When a logical unit is aborting one or more tasks received on an l_T nexus using the TASK ABORTED status it 
should complete all of those tasks before entering additional tasks received on that l_T nexus into the task set. 
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5.8 Command processing examples 

5.8.1 Unlinked command example 

An unlinked command is used to show the events associated with the processing of a single device service request 
(see figure 33). This example does not include error or exception conditions. 



Figure 33 — Command processing events 


The numbers in figure 33 identify the events described as follows: 


1. The application client task performs an Execute Command procedure call by invoking the Send SCSI 
Command SCSI transport protocol service to send the CDB and other input parameters to the logical unit. 

2. The device server is notified through a SCSI Command Received indication containing the CDB and 
command parameters. A task is created and entered into the task set. The device server may invoke the 
appropriate data delivery service one or more times to complete command processing. 

3. The task ends upon completion of the command. On command completion, the Send Command 
Complete SCSI transport protocol service is invoked to return a status of GOOD and a service response 

of TASK COMPLETE. 

4. A confirmation of Command Complete Received is passed to the application client task by the SCSI 
initiator port. 
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5.8.2 Linked command example 

A task may consist of multiple commands linked together. After the logical unit notifies the application client that a 
linked command has successfully completed, the application client issues the next command in the series. 

The example in figure 34 shows the events in a series of two linked commands. 


Initiator 

Application Client Task 



Device Server 


Figure 34 — Linked command processing events 

The numbers in figure 34 Identify the events described as follows: 

1. The application client task performs an Execute Command procedure call by invoking the Send SCSI 
Command SCSI transport protocol service to send the CDB and other input parameters to the logical unit. 
The link bit is set to one in the CDB control byte (see 5.2). 

2. The device server is notified through a SCSI Command Received indication containing the CDB and 
command parameters. A task (Task A) is created and entered into the task set. 

3. Upon completion of the first command, the device server invokes the Send Command Complete SCSI 
transport protocol service with the status set to INTERMEDIATE or INTERMEDIATE-CONDITION MET 
and a service response of linked command complete. Task A is not terminated. 

4. The SCSI initiator port returns the status and service response to the application client task by means of a 

Command Complete Received confirmation. 

5. The application client task performs an Execute Command procedure call by means of the Send SCSI 
Command SCSI transport protocol service as described in step 1. The Task Attribute argument is omitted. 
The link bit in the CDB control byte is set to zero. 

6. The device server receives the last command in the series and processes the operation. 

7. The command completes successfully. Task A is terminated. A Send Command Complete SCSI transport 
protocol service response of task complete, with status GOOD, is sent to the application client. 

8. The SCSI initiator port delivers an Command Complete Received confirmation containing the service 
response and status to the application client task. 
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5.9 Command processing considerations and exception conditions 

5.9.1 Commands that complete with CHECK CONDITION status 

5.9.1.1 Overview 

When a command completes with a CHECK CONDITION status, the application client may request that the device 
server alter command processing by establishing an ACA condition, using the naca bit in the control byte of the 
CDB as follows: 

a) If the naca bit is set to zero, an ACA condition shall not be established; or 

b) If the naca bit is set to one, an ACA condition shall be established (see 5.9.2). 

The requirements that apply when the ACA condition is not in effect are described in 5.9.1.2. 

When a command completes with a CHECK CONDITION status and an ACA condition is not established, tasks 
other than the task for the command returning the CHECK CONDITION status may be aborted as described in 
5.9.1.3. 

5.9.1.2 Handling tasks when ACA is not in effect 

Table 24 describes the handling of tasks when an ACA condition is not in effect for the task set. Which l_T nexuses 
are associated with the task set is influenced by the tst field in the Control mode page (see SPC-3). 


Table 24 — Task handling when ACA is not in effect 


New Task Properties 


ACA Established if New 

Task Terminates with 
a CHECK CONDITION status 

Attribute a 

naca Value b 

Device Server Action 

Any Attribute 

0 


No 

Except ACA 

1 

— Process the task. c — 

Yes 

ACA 

0 

Process an invalid task attribute 

No 

1 

— condition as described in 5.9.5. _ 

Yes 


a Task attributes are described in 8.6. 
b The naca bit is in the control byte in the CDB (see 5.2). 

c All the conditions that affect the processing of commands (e.g., reservations) apply. 


5.9.1.3 Aborting other tasks when CHECK CONDITION status is returned without establishing an ACA 

When a CHECK CONDITION status is returned for a command where the naca bit is set to zero in the command’s 
CDB control byte (i.e., when an ACA condition is not established), tasks in the dormant or enabled task state 
(see 8.5) may be aborted based on the contents of the tst field and QErr field in the Control mode page (see 
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SPC-3) as shown in table 25. The tst field specifies the type of task set in the logical unit. The QErr field specifies 
how the device server handles blocked and dormant tasks when another task receives a CHECK CONDITION 
status. 


Table 25 — Aborting tasks when an ACA is not established 


QErr 

TST 

Action 

00b 

000b 

001b 

Tasks other than the task returning CHECK CONDITION status shall not be aborted. 

01b 

000b 

All enabled and dormant tasks received on all l_T nexuses shall be aborted (see 5.7). 

001b 

All enabled and dormant tasks received on the l_T nexus on which the CHECK CONDITION 
status was returned shall be aborted (see 5.7). All tasks received on other l_T nexuses shall 
not be aborted. 

11b 

000b 

001b 

All enabled and dormant tasks received on the l_T nexus on which the CHECK CONDITION 
status was returned shall be aborted (see 5.7). All tasks received on other l_T nexuses shall 
not be aborted. 


5.9.2 Auto contingent allegiance (ACA) 

5.9.2.1 ACA Overview 

When a command completes with a CHECK CONDITION status, the application client may request that the device 
server alter command processing by establishing an ACA condition, using the naca bit in the control byte of the 
CDB as follows: 

a) If the naca bit is set to zero, an ACA condition shall not be established (see 5.9.1.1); or 

b) If the naca bit is set to one, an ACA condition shall be established. 

The steps taken by the device server to establish an ACA condition are described in 5.9.2.2. Upon establishment of 
the ACA condition, some tasks other than the task returning the CHECK CONDITION status may be aborted and 
continued processing of other tasks may be blocked as described in 5.9.2.2. 

While the ACA condition is in effect and the tmf_only bit is set to zero in the Control mode page (see SPC-3), new 
tasks received by the logical unit from the faulted l_T nexus are not allowed to enter the task set unless they have 
the ACA task attribute (see 8.6.5). One of the results of the ACA task attribute requirement is that commands 
in-flight when the CHECK CONDITION status occurs are returned unprocessed with an ACA ACTIVE status. 
Multiple commands may be sent one at a time using the ACA task attribute to recover from the event that resulted 
in the ACA condition without clearing the ACA. 

While the ACA condition is in effect and the tmf_only bit is set to one, no new tasks received by the logical unit 
from the faulted l_T nexus are allowed to enter the task set. 

While the ACA condition is in effect: 

a) New tasks received on the faulted l_T nexus shall be handled as described in 5.9.2.3, and 

b) New tasks received on l_T nexuses other than the faulted l_T nexus shall be handled as described in 
5.9.2.4. 

The methods for clearing an ACA condition are described in 5.9.2.5. 
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5.9.2.2 Establishing an ACA 

When a device server terminates a command with a CHECK CONDITION status and the naca bit was set to one in 
the control byte of the faulting command, the device server shall create an ACA condition. 

When an ACA condition is established, tasks in the dormant or enabled task state (see 8.5) shall either be aborted 
or blocked based on the contents of the tst field and QErr field in the Control mode page (see SPC-3) as shown 
in table 26. The tst field specifies the type of task set in the logical unit. The QErr field specifies how the device 
server handles blocked and dormant tasks when another task receives a CHECK CONDITION status. 


Table 26 — Blocking and aborting tasks when an ACA is established 


QErr 

TST 

Action 

00b 

000b 

All enabled tasks received on all l_T nexuses shall transition to the blocked task state (see 
8.8). All dormant tasks received on all l_T nexuses shall remain in the dormant task state. 


001b 

All enabled tasks received on the faulted l_T nexus shall transition to the blocked task state 
(see 8.8). All dormant tasks received on the faulted l_T nexus shall remain in the dormant 
task state. All tasks received on l_T nexuses other than the faulted l_T nexus shall not be 
affected by the establishment of this ACA condition. 

01b 

000b 

All enabled and dormant tasks received on all l_T nexuses shall be aborted (see 5.7). 


001b 

All enabled and dormant tasks received on the faulted l_T nexus shall be aborted (see 5.7). 
All tasks received on l_T nexuses other than the faulted l_T nexus shall not be affected by 
the establishment of this ACA condition. 

11b 

000b 

All enabled and dormant tasks received on the faulted l_T nexus shall be aborted (see 5.7). 
All enabled tasks received on l_T nexuses other than the faulted l_T nexus shall transition to 
the blocked task state (see 8.8). All dormant tasks received on l_T nexuses other than the 
faulted l_T nexus shall remain in the dormant task state. 


001b 

All enabled and dormant tasks received on the faulted l_T nexus shall be aborted (see 5.7). 
All tasks received on l_T nexuses other than the faulted l_T nexus shall not be affected by 
the establishment of this ACA condition. 


An ACA condition shall not cross task set boundaries and shall be preserved until it is cleared as described in 
5.9.2.5. 

If the SCSI transport protocol does not enforce state synchronization as described in 4.6.2, there may be a time 
delay between the occurrence of the ACA condition and the time at which the application client becomes aware of 
the condition. 
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5.9.2.3 Handling new tasks received on the faulted l_T nexus when ACA is in effect 

Table 27 describes the handling of new tasks received on the faulted l_T nexus when ACA is in effect. 


Table 27 — Handling for new tasks received on a faulted l_T nexus during ACA 


New Task Properties 

ACA Task 
Present 
in the 
Task Set 



ACA Established If 

New Task Terminates 
with a CHECK 
CONDITION status 

Attribute a 

NACA 

Value b 

TMF_ONLY 

value c 

Device Server Action 


0 

No 

0 


No d 

ACA 

1 

No 

0 


Yes d 

n/a 

n/a 

1 

Terminate the task with 

n/a 


0 or 1 

Yes 

n/a 

— ACA ACTIVE status. ~ 

n/a 

Any Attribute 
Except ACA 

0 or 1 

n/a 

n/a 

Terminate the task with 
ACA ACTIVE status. 

n/a 


a Task attributes are described in 8.6. 
b The naca bit is in the control byte in the CDB (see 5.2). 
c The tmf_only bit is in the Control mode page (see SPC-3). 

d If a task with the ACA attribute terminates with a CHECK CONDITION status, the existing ACA condition 
shall be cleared and the value of the naca bit shall control the establishment of a new ACA condition. 
e All the conditions that affect the processing of commands (e.g., reservations) apply. 


5.9.2.4 Handling new tasks received on non-faulted I T nexuses when ACA is in effect 

5.9.2.4.1 Command processing permitted for tasks received on non-faulted l_T nexuses during ACA 

The device server shall process a PERSISTENT RESERVE OUT command with a PREEMPT AND ABORT 
service action (see SPC-3) while an ACA condition is established when the command is received on a non-faulted 
l_T nexus. 

NOTE 8 - The processing of specific commands (e.g., PERSISTENT RESERVE OUT command with a PREEMPT 
AND ABORT service action) received on a non-faulted l_T nexus while an ACA condition is in effect provides SCSI 
initiator ports not associated with the faulted l_T nexus the opportunity to recover from error conditions that the 
initiator port associated with the faulted l_T nexus is unable to recover from itself. 
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5.9.2.4.2 Handling new tasks received on non-faulted l_T nexuses when ACA is in effect 

The handling of tasks received on l_T nexuses other than the faulted l_T nexus depends on the value in the tst 
field in the Control mode page (see SPC-3). 

Table 28 describes the handling of new tasks received on l_T nexuses other than the faulted l_T nexus when ACA 
is in effect. 


Table 28 — Handling for new tasks received on non-faulted l_T nexuses during ACA 


tst Field 
Value in 
Control 
mode 
page 

New Task 
Properties 

New 

Command 
Permitted 
During 
ACA c 

Device Server Action 

ACA Established If New 
Task Terminates with 
a CHECK CONDITION 
status 

Attri¬ 
bute a 

NACA 

Value b 

000b 

ACA 

n/a 

n/a 

Terminate the task with 

ACA ACTIVE status. 

n/a 

Any 

Attribute 

Except 

ACA 

0 

No 

Terminate the task with 
BUSY status. 

n/a 

1 

No 

Terminate the task with 

ACA ACTIVE status. 

n/a 

0 

Yes 


No d 

1 

Yes 

Process the task. 

Yes d 

001b 

ACA 

0 

n/a 

Process an invalid task 

No 

1 

described in 5.9.5. 

Yes 

Any 

Attribute 

Except 

ACA 

0 or 1 

n/a 

Process the task. e 

See 5.9.1.2. 


a Task attributes are described in 8.6. 
b The naca bit is in the control byte in the CDB (see 5.2). 
c See 5.9.2.4.1. 

d If a permitted command terminates with a CHECK CONDITION status, the existing ACA condition shall be 
cleared and the value of the naca bit shall control the establishment of a new ACA condition. 
e When the tst field in the Control mode page contains 001b, commands received on a non-faulted l_T 
nexus shall be processed as if the ACA condition does not exist (see 5.9.1.2). In this case, the logical unit 
shall be capable of handling concurrent ACA conditions and sense data associated with each l_T nexus. 


5.9.2.5 Clearing an ACA condition 

An ACA condition shall only be cleared: 

a) As a result of a hard reset (see 6.3.2), logical unit reset (see 6.3.3), or l_T nexus loss (see 6.3.4); 

b) By a CLEAR ACA task management function (see 7.4) received on the faulted l_T nexus; 

c) By a PERSISTENT RESERVE OUT command with a PREEMPT AND ABORT service action with the aca 
task attribute received on the faulted l_T nexus that clears the tasks received on the faulted l_T nexus (see 
SPC-3); 
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d) By a PERSISTENT RESERVE OUT command with a PREEMPT AND ABORT service action with a task 
attribute other than aca received on a non-faulted l_T nexus that clears the tasks received on the faulted 
l_T nexus; 

e) When a command with the aca task attribute received on the faulted l_T nexus terminates with a CHECK 
CONDITION status; or 

f) When a PERSISTENT RESERVE OUT command with a PREEMPT AND ABORT service action termi¬ 
nates in a CHECK CONDITION status. 

Cases e) and f) may result in the establishment of a new ACA based on the value of the naca bit. 

When an ACA condition is cleared and no new ACA condition is established, the state of all tasks in the task set 
shall be modified as described in 8.8. 

5.9.3 Overlapped commands 

An overlapped command occurs when a task manager detects the use of a duplicate l_T_L_G nexus (see 4.11) in 
a command before a task holding that l_T_L_G nexus completes its task lifetime (see 5.5). Each SCSI transport 
protocol standard shall specify whether or not a task manager is required to detect overlapped commands. 

A task manager that detects an overlapped command shall abort all tasks received on the l_T nexus on which the 
overlapped command was received and the device server shall return CHECK CONDITION status for the 
overlapped command. The sense key shall be set to ABORTED COMMAND and the additional sense code shall 
be set to OVERLAPPED COMMANDS ATTEMPTED. 

NOTE 9 - An overlapped command may be indicative of a serious error and, if not detected, may result in corrupted 
data. This is considered a catastrophic failure on the part of the SCSI initiator device. Therefore, vendor specific 
error recovery procedures may be required to guarantee the data integrity on the medium. The SCSI target device 
logical unit may return additional sense data to aid in this error recovery procedure (e.g., sequential-access devices 
may return the residue of blocks remaining to be written or read at the time the second command was received). 

5.9.4 Incorrect logical unit selection 

The SCSI target device's response to an incorrect logical unit number is described in this subclause. 

In response to a REOUEST SENSE command, a REPORT LUNS command, or an INGUIRY command the SCSI 
target device shall respond as defined in SPC-3. 

Any command except REOUEST SENSE, REPORT LUNS, or INGUIRY: 

a) Shall be terminated with CHECK CONDITION status, with the sense key set to ILLEGAL REGUEST, and 
with the additional sense code set to LOGICAL UNIT NOT SUPPORTED, if: 

A) The SCSI target device is not capable of supporting the logical unit (e.g., some SCSI target devices 
support only one peripheral device); or 

B) The SCSI target device supports the logical unit, but the peripheral device is not currently connected to 
the SCSI target device; 

or 

b) Is responded to in a vendor specific manner, if: 

A) The SCSI target device supports the logical unit and the peripheral device is connected, but the 
peripheral device is not operational; or 

B) The SCSI target device supports the logical unit but is incapable of determining if the peripheral device 
is connected or is not operational because the peripheral device is not ready. 
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5.9.5 Task attribute exception conditions 

If a command is received with a task attribute that is not supported or is not valid (e.g., an aca task attribute when 
an ACA condition does not exist), the command shall be terminated with CHECK CONDITION status, sense key 
set to ILLEGAL REQUEST, and additional sense code set to INVALID MESSAGE ERROR. 

NOTE 10 - The use of the INVALID MESSAGE ERROR additional sense code is based on its similar usage in 
previous versions of this standard. The use of the INVALID MESSAGE ERROR additional sense code is not to be 
interpreted as a description of how the task attributes are represented by any given SCSI transport protocol. 

Task attribute support should be reported with the Extended INQUIRY Data VPD page (see SPC-3). 

5.9.6 Sense data 

Sense data shall be made available by the logical unit in the event a command completes with a CHECK 
CONDITION status or other conditions (e.g., the processing of a REQUEST SENSE command). The format, 
content, and conditions under which sense data shall be prepared by the logical unit are specified in this standard, 
SPC-3, the applicable command standard, and the applicable SCSI transport protocol standard. 

Sense data associated with an l_T nexus shall be preserved by the logical unit until: 

a) The sense data is transferred; 

b) A logical unit reset (see 6.3.3) occurs; or 

c) An l_T nexus loss (see 6.3.4) occurs for the l_T nexus associated with the preserved sense data. 

When a command completes with a CHECK CONDITION status, sense data shall be returned in the same 
l_T_L_Q nexus transaction (see 3.1.47) as the CHECK CONDITION status. After the sense data is returned, it 
shall be cleared except when it is associated with a unit attention condition and the ua_intlck_ctrl field in the 
Control mode page (see SPC-3) contains 10b or 11b. 

The return of sense data in the same l_T_L_Q nexus transaction as a CHECK CONDITION status shall not affect 
ACA (see 5.9.2) or the sense data associated with a unit attention condition when the ua_intlck_ctrl field 
contains 10b or 11b. 

5.9.7 Unit Attention condition 

Each logical unit shall generate a unit attention condition whenever one of the following events occurs: 

a) A hard reset (see 6.3.2), logical unit reset (see 6.3.3), or l_T nexus loss (see 6.3.4) occurs; 

b) A removable medium may have been changed; 

c) The mode parameters associated with this l_T nexus have been changed by a task received on another 
l_T nexus (i.e., initiator ports share mode parameters, see SPC-3); 

d) The log parameters associated with this l_T nexus have been changed by a task received on another l_T 
nexus (i.e., initiator ports share log parameters, see SPC-3); 

e) The version or level of microcode has been changed (see SPC-3); 

f) Tasks received on this l_T nexus have been cleared by a task or a task management function associated 
with another l_T nexus and the tas bit was set to zero in the Control mode page associated with this l_T 
nexus (see SPC-3); 

g) INQUIRY data has been changed (see SPC-3); 

h) The logical unit inventory has been changed (see SPC-3); 

i) The mode parameters in effect for the associated l_T nexus have been restored from non-volatile memory 
(see SPC-3); or 

j) Any other event requiring the attention of the SCSI initiator device. 
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Logical units may queue unit attention conditions. After the first unit attention condition is cleared, another unit 
attention condition may exist (e.g., a unit attention condition with an additional sense code set to POWER ON 
OCCURRED may be followed by one with an additional sense code set to MICROCODE HAS BEEN CHANGED). 

A unit attention condition shall persist on the logical unit for the SCSI initiator port associated with each l_T nexus 
until the SCSI initiator port associated with the l_T nexus clears the condition as described in the remainder of this 
subclause. 

If an INQUIRY command enters the enabled task state, the logical unit shall perform the INQUIRY command and 
shall neither report nor clear any unit attention condition. 

If a REPORT LUNS command enters the enabled task state, the logical unit shall perform the REPORT LUNS 
command and shall not report any unit attention condition. For each logical unit accessible by the l_T nexus on 
which the REPORT LUNS command was received, any pending unit attention condition established for the initiator 
port associated with that l_T nexus as a result of a change in the logical unit inventory shall be cleared. Other 
pending unit attention conditions shall not be cleared. 

If a REQUEST SENSE command enters the enabled task state while a unit attention condition exists for the SCSI 
initiator port associated with the l_T nexus on which the REQUEST SENSE command was received, then the 
logical unit shall return GOOD status and either: 

a) Report any pending sense data as parameter data and preserve all unit attention conditions on the logical 
unit; or, 

b) Report a unit attention condition as parameter data for the REQUEST SENSE command to the SCSI 
initiator port associated with the l_T nexus on which the REQUEST SENSE command was received. The 
logical unit may discard any pending sense data and shall clear the reported unit attention condition for the 
SCSI initiator port associated with that l_T nexus. 

If the logical unit has already generated the ACA condition (see 5.9.2) for a unit attention condition, the logical unit 
shall report the unit attention condition (i.e., option b) above). 

If a command other than INQUIRY, REPORT LUNS, or REQUEST SENSE enters the enabled task state while a 
unit attention condition exists for the SCSI initiator port associated with the l_T nexus on which the command was 
received, the logical unit shall terminate the command with a CHECK CONDITION status. The logical unit shall 
provide sense data that reports a unit attention condition for the SCSI initiator port that sent the command on the 
l_T nexus. 

If a logical unit reports a unit attention condition with a CHECK CONDITION status and the ua_intlck_ctrl field in 
the Control mode page contains 00b (see SPC-3), then the logical unit shall clear the reported unit attention 
condition for the SCSI initiator port associated with that l_T nexus on the logical unit. If the ua_intlck_ctrl field 
contains 10b or 11b, the logical unit shall not clear unit attention conditions reported with a CHECK CONDITION 
status. 
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6 SCSI events and event notification model 
6.1 SCSI events overview 

SCSI events may occur or be detected in either: 

a) The SCSI device; 

b) One or more SCSI ports within a SCSI device; or 

c) The application client, task manager, or device server. 

The detection of any event may require processing by the object that detects it. 

Events that occur in the SCSI device are assumed to be detected and processed by all objects within the SCSI 
device. 

When a SCSI port detects an event, it shall use the event notification services (see 6.4) to notify SCSI application 
layer objects that the event has been detected. 

The events detected and event notification services usage depends on whether the SCSI device is a SCSI target 
device (see figure 35) or a SCSI initiator device (see figure 36). SCSI target/initiator devices shall use the event 
notification services defined for both SCSI target devices and SCSI initiator devices. 



Key 


Event 


^ Condition j 


Notification mechanism not 
specified in this standard 

-.-^ Notification mechanism 

Service Name specified in this standard 


Figure 35 — Events and event notifications for SCSI target devices 
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Key 


Event 


Condition 


Notification mechanism not 
specified in this standard 

_^ Notification mechanism 

Service Name specified in this standard 


Figure 36 — Events and event notifications for SCSI initiator devices 


6.2 Establishing a unit attention condition subsequent to detection of an event 

Table 29 shows the additional sense code that a logical unit shall use when a unit attention (see 5.9.7) is estab¬ 
lished for each of the conditions shown in figure 35 (see 6.1). A SCSI transport protocol may define a more specific 
additional sense code than SCSI BUS RESET OCCURRED for reset events. The most specific condition in table 
29 known to the logical unit should be used to establish the additional sense code for a unit attention. 


Table 29 — Unit attention additional sense codes for events detected by SCSI target devices 


Condition 

Additional Sense Code 

Specificity 

Logical unit is unable to distin¬ 
guish between the conditions 

POWER ON, RESET, OR BUS DEVICE RESET 
OCCURRED 

Lowest 

Power on 

POWER ON OCCURRED or 

DEVICE INTERNAL RESET 


Hard reset 

SCSI BUS RESET OCCURRED or 
protocol specific 


Logical unit reset 

BUS DEVICE RESET FUNCTION OCCURRED 


l T nexus loss 

l T NEXUS LOSS OCCURRED 

Highest 


NOTE 11 - The names of the unit attention conditions listed in the subclause (e.g., SCSI BUS RESET 
OCCURRED) are based on usage in previous versions of this standard. The use of these unit attention condition 
names is not to be interpreted as a description of how the unit attention conditions are represented by any given 
SCSI transport protocol. 


dpANS SCSI Architecture Model - 3 (SAM-3) 


























































T10/1561-D revision 14 


21 September 2004 


A logical unit may use the l_T NEXUS LOSS OCCURRED additional sense code when establishing a unit attention 
condition if: 

a) The SCSI initiator port to which the sense data is being delivered is the SCSI initiator port that was 
associated with the l_T nexus loss, and the logical unit has maintained all state information specific to that 
SCSI initiator port since the l_T nexus loss; and 

b) The l_T nexus being used to deliver the sense data is the same l_T nexus that was lost, and the logical 
unit has maintained all state information specific to that l_T nexus since the l_T nexus loss. 

Otherwise, the logical unit shall use one of the less specific additional sense codes (e.g., POWER ON 
OCCURRED) when establishing a unit attention condition. 


6.3 Conditions resulting from SCSI events 

6.3.1 Power on 

Power on is a SCSI device condition resulting from a power on event. When a SCSI device is powered on, it shall 
cause a hard reset. 

The power on condition applies to both SCSI initiator devices and SCSI target devices. 

6.3.2 Hard reset 

Hard reset is a SCSI device condition resulting from: 

a) A power on condition (see 6.3.1); or 

b) A reset event indicated by a Transport Reset event notification (see 6.4). 

The definition of reset events and the notification of their detection is SCSI transport protocol specific. 

Each SCSI transport protocol standard that defines reset events shall specify a SCSI target port’s protocol specific 
actions in response to reset events. Each SCSI transport protocol standard that defines reset events should specify 
when those events result in the delivery of a Transport Reset event notification to the SCSI applications layer. 

SCSI transport protocols may include reset events that have no SCSI effects (e.g., a Fibre Channel non-initializing 
loop initialization primitive). 

The hard reset condition applies to both SCSI initiator devices and SCSI target devices. 

A SCSI target port’s response to a hard reset condition shall include a logical unit reset condition (see 6.3.3) for all 
logical units to which the SCSI target port has access. A hard reset condition shall not affect any other SCSI target 
ports in the SCSI target device, however, the logical unit reset condition established by a hard reset may affect 
tasks that are communicating via other SCSI target ports. 

Although the task manager response to task management requests is subject to the presence of access restric¬ 
tions, as managed by ACCESS CONTROL OUT commands (see SPC-3), a hard reset condition shall not be 
prevented by access controls. 

When a SCSI initiator port detects a hard reset condition, it should terminate all its outstanding Execute 
Command procedure calls with a service response of service delivery or target failure. A hard reset condition 
shall not affect any other SCSI initiator ports in the SCSI initiator device, however, the logical unit reset condition 
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established in a SCSI target device by a hard reset may affect tasks that are communicating via other SCSI initiator 
ports. 

A SCSI port’s response to a hard reset condition shall include establishing an l_T nexus loss condition (see 6.3.4) 
for every l_T nexus associated with that SCSI port. 

6.3.3 Logical unit reset 

Logical unit reset is a logical unit condition resulting from: 

a) A hard reset condition (see 6.3.2); or 

b) A logical unit reset event indicating that a LOGICAL UNIT RESET task management request (see 7.6) has 
been processed. 

The logical unit reset condition applies only to SCSI target devices. 

When responding to a logical unit reset condition, the logical unit shall: 

a) Abort all tasks as described in 5.7; 

b) Clear all ACA conditions (see 5.9.2.5) in all task sets in the logical unit; 

c) Establish a unit attention condition (see 5.9.7 and 6.2); 

d) Initiate a logical unit reset for all dependent logical units (see 4.14); and 

e) Perform any additional functions required by the applicable command standards. 

6.3.4 l_T nexus loss 

l_T nexus loss is a SCSI device condition resulting from: 

a) A hard reset condition (see 6.3.2); or 

b) An l_T nexus loss event (e.g., logout) indicated by a Nexus Loss event notification (see 6.4). 

An l_T nexus loss event is an indication from the SCSI transport protocol to the SCSI application layer that an l_T 
nexus no longer exists. SCSI transport protocols may define l_T nexus loss events. 

Each SCSI transport protocol standard that defines l_T nexus loss events should specify when those events result 
in the delivery of a Nexus Loss event notification to the SCSI applications layer. 

The l_T nexus loss condition applies to both SCSI initiator devices and SCSI target devices. 

When a SCSI target port detects an l_T nexus loss, a Nexus Loss event notification indication shall be delivered to 
each logical unit to which the l_T nexus has access. In response to the resulting l_T nexus loss condition a logical 
unit shall take the following actions: 

a) Abort all tasks received on the l_T nexus as described in 5.7; 

b) Clear all ACA conditions (see 5.9.2.5) associated with the l_T nexus; 

c) Establish a unit attention condition for the SCSI initiator port associated with the l_T nexus (see 5.9.7 and 
6.2); and 

d) Perform any additional functions required by the applicable command standards. 

If the logical unit retains state information for the l_T nexus that is lost, its response to the subsequent l_T nexus 
re-establishment for the logical unit should include establishing a unit attention with an additional sense code set to 
l_T NEXUS LOSS OCCURRED. 
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If the logical unit does not retain state information for the l_T nexus that is lost, it shall consider the subsequent l_T 
nexus re-establishment, if any, as the formation of a new l_T nexus for which there is no past history (e.g., establish 
a unit attention with an additional sense code set to POWER ON OCCURRED). 

When a SCSI initiator port detects an l_T nexus loss, it should terminate all its outstanding Execute Command 
procedure calls and Send Task Management Request procedure calls for the SCSI target port associated with 
the l_T nexus with a service response of service delivery or target failure. 


6.4 Event notification SCSI transport protocol services 

The SCSI transport protocol services described in this subclause are used by a SCSI initiator port or a SCSI target 
port to deliver an indication to the SCSI application layer that a SCSI event has been detected. 

All SCSI transport protocol standards should define the SCSI transport protocol specific requirements for imple¬ 
menting the Nexus Loss indication and the Transport Reset indication described in this subclause and when 
these indications are to be delivered to the SCSI applications layer. 

The Nexus Loss and the Transport Reset indications are defined for both SCSI target devices and SCSI initiator 
devices. 

Indication delivered to device servers and application clients: 

Nexus Loss (IN (I T Nexus )) 

Argument description: 

l_T Nexus: The specific l_T nexus that has been detected as lost. 

Indication delivered to device servers and application clients: 

Transport Reset (IN ( SCSI Port)) 

Argument descriptions: 

SCSI Port: The specific SCSI port in the SCSI device for which a transport reset was detected. 
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7 Task management functions 
7.1 Introduction 


An application client requests the processing of a task management function by invoking the SCSI transport 
protocol services described in 7.8, the collective operation of which is modeled in the following procedure call: 

Service Response = Function name (IN ( nexus )) 

The task management function names are summarized in table 30. 


Table 30 — Task Management Functions 


Task Management Function 

Nexus 

Reference 

ABORT TASK 

l_T_L_Q 

7.2 

ABORT TASK SET 

l_T_L 

7.3 

CLEAR ACA 

l_T_L 

7.4 

CLEAR TASK SET 

l_T_L 

7.5 

LOGICAL UNIT RESET 

l_T_L 

7.6 

QUERY TASK 

l_T_L_Q 

7.7 


Argument descriptions: 

Nexus: 

l_T Nexus: 
l_T_L Nexus: 
l_T_L_Q Nexus: 


An l_T Nexus, l_T_L Nexus, or l_T_L_Q Nexus (see 4.12) identifying the task or 
tasks affected by the task management function. 

A SCSI initiator port and SCSI target port nexus (see 4.12). 

A SCSI initiator port, SCSI target port, and logical unit nexus (see 4.12). 

A SCSI initiator port, SCSI target port, logical unit, and task tag nexus (see 4.12). 


Service Response: 


One of the following SCSI transport protocol specific responses shall be returned: 


function complete: A task manager response indicating that the requested function is complete. 

Unless another response is required, the task manager shall return this 
response upon completion of a task management request supported by the 
logical unit or SCSI target device to which the request was directed. 
function succeeded: An optional task manager response indicating that the requested function is 
supported and completed successfully. This task manager response shall only 
be used by functions that require notification of success. 


function rejected: An task manager response indicating that the requested function is not 
supported by the logical unit or SCSI target device to which the function was 
directed. 


INCORRECT LOGICAL UNIT 

number: 


An optional task manager response indicating that the function requested 
processing for an incorrect logical unit number. 


service delivery The request was terminated due to a service delivery failure (see 3.1.112) or 
or target failure: SCSI target device malfunction. The task manager may or may not have 
successfully performed the specified function. 


Each SCSI transport protocol standard shall define the events comprising each of these service responses. 
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The task manager response to task management requests is subject to the presence of access restrictions, as 
managed by ACCESS CONTROL OUT and ACCESS CONTROL IN commands (see SPC-3), as follows: 

a) A task management request of ABORT TASK, ABORT TASK SET, CLEAR ACA, or QUERY TASK shall not 
be affected by the presence of access restrictions; 

b) A task management request of CLEAR TASK SET or LOGICAL UNIT RESET received from a SCSI 
initiator port that is denied access to the logical unit, either because it has no access rights or because it is 
in the pending-enrolled state, shall not cause any changes to the logical unit; and 

c) The task management function service response shall not be affected by the presence of access restric¬ 
tions. 


7.2 ABORT TASK 

Request: 

Service Response = ABORT TASK (IN (l_T_L_Q Nexus )) 

Description: 

This function shall be supported by all logical units. 

The task manager shall abort the specified task, if any, as described in 5.7.2. Previously established conditions, 
including MODE SELECT parameters, reservations, and ACA shall not be changed by the ABORT TASK function. 

A response of function complete shall indicate that the task was aborted or was not in the task set. In either case, 
the SCSI target device shall guarantee that no further requests or responses are sent from the task. 

All SCSI transport protocol standards shall support the ABORT TASK task management function. 


7.3 ABORT TASK SET 

Request: 

Service Response = ABORT TASK SET (IN (l_T_L Nexus )) 

Description: 

This function shall be supported by all logical units. 

The task manager shall abort all tasks in the task set that were received on the specified l_T nexus as described in 
5.7. Tasks received on other l_T nexuses or in other task sets shall not be aborted. This task management function 
performed is equivalent to a series of ABORT TASK requests. 

Other previously established conditions, including MODE SELECT parameters, reservations, and ACA shall not be 
changed by the ABORT TASK SET function. 

All SCSI transport protocol standards shall support the ABORT TASK SET task management function. 
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7.4 CLEAR ACA 

Request 

Service Response = CLEAR ACA (IN (l_T_L Nexus )) 

Description: 

This function shall be supported by a logical unit if it supports ACA (see 5.2). 

For the CLEAR ACA task management function, the task set shall be the one defined by the tst field in the Control 
mode page (see SPC-3). 

An application client requests a CLEAR ACA using the faulted l_T nexus (see 3.1.33) to clear an ACA condition 
from the task set serviced by the logical unit. The state of all tasks in the task set shall be modified as described in 
8.8. For a task with the ACA attribute (see 8.6.5) receipt of a CLEAR ACA function shall have the same effect as 
receipt of an ABORT TASK function (see 7.2) specifying that task. If successful, this function shall be terminated 
with a service response of function complete. 

If the task manager clears the ACA condition, any task within that task set may be completed subject to the require¬ 
ments for task set management specified in clause 8. 

The service response for a CLEAR ACA request received from an l_T nexus other than the faulted l_T nexus shall 
be FUNCTION REJECTED. 

All SCSI transport protocol standards shall support the CLEAR ACA task management function. 


7.5 CLEAR TASK SET 

Request: 

Service Response = CLEAR TASK SET (IN (l_T_L Nexus )) 

Description: 

This function shall be supported by logical units supporting the full task management model (see 8.3.2) and may 
be supported by logical unit supporting the basic task management model (see 8.3.3). 

For the CLEAR TASK SET task management function, the task set shall be the one defined by the tst field in the 
Control mode page (see SPC-3). 

All tasks in the task set shall be aborted as described in 5.7. 

All pending status and sense data for the task set shall be cleared. Other previously established conditions, 
including MODE SELECT parameters, reservations, and ACA shall not be changed by the CLEAR TASK SET 
function. 

All SCSI transport protocol standards shall support the CLEAR TASK SET task management function. 
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7.6 LOGICAL UNIT RESET 

Request: 

Service Response = LOGICAL UNIT RESET (IN (l_T_L Nexus )) 

Description: 

This function shall be supported by all logical units. 

Before returning a function complete response, the logical unit shall perform the logical unit reset functions 
specified in 6.3.3. 

NOTE 12 - Previous versions of this standard only required LOGICAL UNIT RESET support in logical units that 
supported hierarchical logical units. 

All SCSI transport protocol standards shall support the LOGICAL UNIT RESET task management function. 


7.7 QUERY TASK 

Request: 

Service Response = QUERY TASK (IN (l_T_L_Q Nexus )) 

Description: 

SCSI transport protocols may or may not support QUERY TASK and may or may not require logical units acces¬ 
sible through SCSI target ports using such transport protocols to support QUERY TASK. 

The task manager shall return a response of function succeeded if the specified task is present in the task set, or 
function complete if the specified task is not present in the task set. 


7.8 Task management SCSI transport protocol services 

The SCSI transport protocol services described in this subclause are used by a SCSI initiator device and SCSI 
target device to process a task management procedure call. The following arguments are passed: 

Nexus: An l_T Nexus, l_T_L Nexus, or l_T_L_Q Nexus (see 4.12). 

Function Identifier: Argument encoding the task management function to be performed. 

All SCSI transport protocol standards shall define the SCSI transport protocol specific requirements for imple¬ 
menting the Send Task Management Request, the Task Management Request Received indication, the Task 
Management Function Executed response, and the Received Task Management Function Executed confir¬ 
mation SCSI transport protocol services described in this subclause. 

A SCSI transport protocol standard may specify different implementation requirements for the Send Task 
Management Request SCSI transport protocol service for different values of the Function Identifier argument. 
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All SCSI initiator devices shall implement the Send Task Management Request and the Received Task 
Management Function Executed confirmation SCSI transport protocol services as defined in the applicable SCSI 
transport protocol standards. 

All SCSI target devices shall implement the Task Management Request Received indication and the Task 
Management Function Executed response SCSI transport protocol services as defined in the applicable SCSI 
transport protocol standards. 

Request sent by an application client: 

Send Task Management Request (IN ( Nexus, Function Identifier)) 

Argument descriptions: 


Nexus: An l_T Nexus, l_T_L Nexus, or l_T_L_Q Nexus (see 4.12). 
Function Identifier: Argument encoding the task management function to be performed. 

Indication received by the task manager: 

Task Management Request Received (IN ( Nexus, Function Identifier)) 

Argument descriptions: 


Nexus: An l_T Nexus, l_T_L Nexus, or l_T_L_Q Nexus (see 4.12). 
Function Identifier: Argument encoding the task management function to be performed. 

Response from task manager: 

Task Management Function Executed (IN ( Nexus, Service Response )) 

Argument descriptions: 


Nexus: 
Service Response: 


An l_T Nexus, l_T_L Nexus, or l_T_L_Q Nexus (see 4.12). 

An encoded value representing one of the following: 

function complete: The requested function has been completed. 
function succeeded: The requested function is supported and completed 
successfully. 

function rejected: The task manager does not implement the requested 
function. 


incorrect logical 
unit number: 


An optional task manager response indicating that the 
function requested processing for an incorrect logical 
unit number. 


service delivery The request was terminated due to a service delivery 
or target failure: failure (see 3.1.112) or SCSI target device malfunction. 

The task manager may or may not have successfully 
performed the specified function. 
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Confirmation received by application client: 

Received Task Management Function Executed (IN ( Nexus, Service Response )) 

Argument descriptions: 


Nexus: An l_T Nexus, l_T_L Nexus, or l_T_L_Q Nexus (see 4.12). 

Service Response: An encoded value representing one of the following: 

function complete: The requested function has been completed. 
function succeeded: The requested function is supported and completed 
successfully. 

function rejected: The task manager does not implement the requested 
function. 


INCORRECT logical 
unit number: 


An optional task manager response indicating that the 
function requested processing for an incorrect logical 
unit number. 


service delivery The request was terminated due to a service delivery 
or target failure: failure (see 3.1.112) or SCSI target device malfunction. 

The task manager may or may not have successfully 
performed the specified function. 


Each SCSI transport protocol shall allow a Received Task Management Function Executed confirming 
completion of the requested task to be associated with the corresponding Send Task Management Request. 
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7.9 Task management function example 

Figure 37 shows the sequence of events associated with a task management function. 



Figure 37 — Task management processing events 


The numbers in figure 37 identify the events described as follows: 

1. The application client task issues a task management request by invoking the Send Task Management 
Request SCSI transport protocol service. 

2. The task manager is notified through a Task Management Request Received and begins processing the 
function. 

3. The task manager performs the requested function and responds by invoking the Task Management 
Function Executed SCSI transport protocol service to notify the application client. The service response 
argument is set to a value of function complete. 

4. A Received Task Management Function Executed confirmation is received by the application client task. 
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8 Task set management 

8.1 Introduction to task set management 

This clause describes some of the controls that application clients have over task set management behaviors (see 
8.3). This clause also specifies task set management requirements in terms of: 

a) Task states (see 8.5); 

b) Task attributes (see 8.6); 

c) Task priority (see 8.7); 

d) The events that cause transitions between task states (see 8.4 and 8.5); and 

e) A map of task state transitions (see 8.8). 

This clause concludes with several task set management examples (see 8.9). 

Task behavior, as specified in this clause, refers to the functioning of a task as observed by an application client, 
including the results of command processing and interactions with other tasks. 

The requirements for task set management only apply to a task after it has been entered into a task set. A task 
shall be entered into a task set unless: 

a) A condition exists that causes that task to be completed with a status of BUSY, RESERVATION 
CONFLICT, TASK SET FULL, or ACA ACTIVE; 

b) Detection of an overlapped command (see 5.9.3) causes that task to be completed with a CHECK 
CONDITION status; or 

c) SCSI transport protocol specific errors cause that task to be completed with CHECK CONDITION status. 


8.2 Implicit head of queue 

A command standard (see 3.1.16) may define commands each of which may be processed by the task manager as 
if the task’s task attribute is head of queue even if the task is received with a simple task attribute, an ordered 
task attribute, or no task attribute. 

An application client should not send a command with the ordered task attribute if the command may be 
processed as if it has a task attribute of head of queue because whether the ordered task attribute is honored is 
vendor specific. 


8.3 Task management models 

8.3.1 Task management model management features 

The standard INCUIRY data CmdGue bit and BCue bit (see SPC-3) indicate support for the full task management 
model or basic task management model described in 8.3. 

The Control mode page (see SPC-3) contains fields that specify particular task set management behaviors 
described in this clause. 
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8.3.2 Full task management model 

The full task management model requires the following task set management behaviors: 

a) The simple task attribute (see 8.6.1) shall be supported; 

b) Task attributes other than simple may be supported; 

c) The queue algorithm modifier field in the Control mode page (see SPC-3) shall control the processing 
sequence of tasks having the simple task attribute; 

d) The QErr field in the Control mode page (see SPC-3) shall control aborting of tasks when a CHECK 
CONDITION status is returned for any task; and 

e) The CLEAR TASK SET task management function (see 7.5) shall be supported. 

8.3.3 Basic task management model 

The basic task management model requires the following task set management behaviors: 

a) The SCSI transport protocol and task manager support only: 

A) The simple task attribute (see 8.6.1); or 

B) The ordered task attribute (see 8.6.3); 

b) If the simple task attribute is supported, the task manager may reorder the actual processing sequence of 
tasks in any manner. Any data integrity exposures related to task sequence order shall be explicitly 
handled by the application client; 

c) All tasks in the task set shall be aborted when a CHECK CONDITION status is returned for any task (i.e., 
they shall be handled as if the QErr field in the Control mode page (see SPC-3) is set to 01b); 

d) If the Control mode page is supported, the queue algorithm modifier field shall be set to 1h and the 
QErr field shall be set to 01b and they shall not be changeable; and 

e) The CLEAR TASK SET task management function (see 7.5) may be supported. 
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8.4 Task management events 

The following describe the events that cause changes in task state. 

All older tasks ended: If the tst field in the Control mode page (see SPC-3) equals 000b, all tasks 
received on all l_T nexuses and accepted earlier in time than the referenced 
task have ended. If the tst field equals 001b, all tasks received on the 
referenced l_T nexus and accepted earlier in time than the referenced task have 
ended. 

All head of queue If the tst field equals 000b, all the following tasks received on all l_T nexuses 
and older ordered tasks have ended: 

ended: a) All head of queue tasks; and 

b) All ordered tasks accepted earlier in time than the referenced task. 

If the tst field equals 001b, the following tasks received on the referenced l_T 
nexus have ended: 

a) All head of queue tasks; and 

b) All ordered tasks accepted earlier in time than the referenced task. 

ACA establishment: An ACA condition has been established (see 5.9.1). 

task abort: A task has been aborted as described in 5.7. 
task completion: The device server has sent a service response of task complete for the task 
(see 5.1 and 5.5). 

task ended: A task has completed or aborted. 

ACA cleared: An ACA condition has been cleared (see 5.9.2.5). 

8.5 Task states 

8.5.1 Overview 

8.5.1.1 Task state nomenclature 

This standard defines four tasks states, summarized in table 31. 


Table 31 — Task State Nomenclature 


Task State Name 

Reference 

Tasks in This State May Be Called 

Enabled task state 

8.5.2 

Enabled tasks 

Blocked task state 

8.5.3 

Blocked tasks 

Dormant task state 

8.5.4 

Dormant tasks 

Ended task state 

8.5.5 

Ended tasks 


8.5.1.2 Suspended information 

Any information the logical unit has or accepts for a task in the blocked task state (see 8.5.3) or dormant task state 
(see 8.5.4) is required to be held in a condition where it is not available to the task. Such information is called 
suspended information. 
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8.5.2 Enabled task state 

A task in the enabled task state may become a current task and may complete at any time, subject to the task 
completion constraints specified in the Control mode page (see SPC-3). A task that has been accepted into the 
task set shall not complete or become a current task unless it is in the enabled task state. 

Except for the use of resources required to preserve task state, a task shall produce no effects detectable by the 
application client before the task's first transition to the enabled task state. Before entering this state for the first 
time, the task may perform other activities visible at the STPL (e.g., pre-fetching data to be written to the media), 
however this activity shall not result in a detectable change in state as perceived by an application client. In 
addition, the behavior of a completed task, as defined by the commands it has processed, shall not be affected by 
the task's states before it enters the enabled task state. 

8.5.3 Blocked task state 

A task in the blocked task state is prevented from completing due to an ACA condition. A task in this state shall not 
become a current task. While a task is in the blocked task state, any information the logical unit has or accepts for 
the task shall be suspended. If the tst field in the Control mode page (see SPC-3) equals 000b the blocked task 
state is independent of l_T nexus. If the tst field equals 001b the blocked task state applies only to the faulted l_T 
nexus. 

8.5.4 Dormant task state 

A task in the dormant task state is prevented from completing due to the presence of certain other tasks in the task 
set. A task in this state shall not become a current task. While a task is in the dormant task state, any information 
the logical unit has or accepts for the task shall be suspended. 

8.5.5 Ended task state 

A task in the ended task state is removed from the task set. 
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8.5.6 Task states and task lifetimes 

Figure 38 shows the events corresponding to two task processing sequences. Except for the dormant task state 
between times A and B in case 1, logical unit conditions and the commands processed by the task are identical. 
Assuming in each case the task completes with a status of GOOD at time C, the state observed by the application 
client for case 1 shall be indistinguishable from the state observed for case 2. 
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- Task Dormant —►j 






Timeline 



\ 
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l 

Task 

Created 
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Task 
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c 

Task Ended X. 

" Application client 
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Case 2 




_1_ 
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i 

Task Created 
and Enabled 

C 

Task Ended 



Figure 38 — Example of Dormant state task behavior 
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8.6 Task attributes 

8.6.1 Overview 

The application client shall assign a task attribute (see table 32) to each task. 

Table 32 — Task attributes 


Task Attribute 

Reference 

SIMPLE 

8.6.2 

ORDERED 

8.6.3 

HEAD OF QUEUE 

8.6.4 

ACA 

8.6.5 


SCSI transport protocols shall either: 

a) Provide the capability to specify a unique task attribute for each task; or 

b) Ignore the application client assigned task attribute and require use of the basic task management model 
(see 8.3.3). 

SCSI transport protocols should provide the capability to specify a unique task attribute for each task. 

8.6.2 Simple task 

If accepted, a task having the simple attribute shall be entered into the task set in the dormant task state. The task 
shall not enter the enabled task state until all head of queue tasks and older ordered tasks in the task set have 
ended (see 8.4). 

The queue algorithm modifier field in the Control mode page (see SPC-3) provides additional constraints on task 
completion order for tasks having the simple task attribute. 

8.6.3 Ordered task 

If accepted, a task having the ordered attribute shall be entered into the task set in the dormant task state. The 
task shall not enter the enabled task state until all head of queue tasks and all older tasks in the task set have 
ended (see 8.4). 

8.6.4 Head of queue task 

If accepted, a task having the head of queue attribute shall be entered into the task set in the enabled task state. 

8.6.5 ACA task 

If accepted, a task having the aca attribute shall be entered into the task set in the enabled task state. There shall 
be no more than one ACA task per task set (see 5.9.2.2). 
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8.7 Task priority 

A task priority argument that if set to a value other than zero specifies the relative scheduling importance of a task 
having a simple task attribute in relation to other tasks already in the task set. Task priority 1h has the highest 
scheduling importance, with increasing task priority values indicating lower scheduling importance. 

If the task priority argument is set to zero or is not contained within the SCSI transport protocol service indication, a 
priority assigned to the l_T_L nexus may be used as the task priority. A priority may be assigned to an l_T_L nexus 
by a SET PRIORITY command (see SPC-3) or by the initial priority field in the Control Extension mode page 
(see SPC-3). If no priority has been assigned to the l_T_L nexus using the SET PRIORITY command and the 
logical unit does not support the initial priority field in the Control Extension mode page the priority assigned to 
the task is vendor specific. 

A task manager may use task priority to determine an ordering to process tasks with the simple task attribute within 
the task set. A difference in task priority between tasks may not override other scheduling considerations (e.g., 
different times to access different logical block addresses) or vendor specific scheduling considerations. However, 
processing of a collection of tasks with different task priorities should cause the subset of tasks with the higher 
priority to return status sooner in aggregate than the same subset would if the same collection of tasks were 
submitted under the same conditions but with all task priorities being equal. 

For a task that processes linked commands, the task priority shall be that specified for the first command in the 
series of linked commands. The task priority specified for the second and subsequent commands shall be ignored. 

The size of the task priority argument shall be four bits. 
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8.8 Task state transitions 

This subclause describes task state transitions, actions and associated triggering events as they appear to an 
application client. The logical unit response to events affecting multiple tasks (e.g., a CLEAR TASK SET) may be 
different from the response to an event affecting a single task. To the application client, the collective behavior 
appears as a series of state changes occurring to individual tasks. 

The task state diagram of figure 39 shows the behavior of a single task in response to an external event. 


SI: Dormant 

SO: New Task 

New task accepted 

S2: Enabled 



S0S2_ ► 



SIMPLE or ORDERED task 
attribute 

HEAD OF QUEUE or ACA task 
attribute 




Cl CO 




No ordering or blocking conditions a 



S4: Ended 

Remove task from task set 

S3: Blocked 






a^|_ j S2‘S3 




^_ S3'S4 

ACA 

Established 

S3 S2 _ ► 




Task Abort 






ACA 

Cleared 



S1S4 _► 


S2'S4 



Task Abort 


Task End 


a ACA is not active and: 

a) For simple tasks, all head of queue and all older ordered tasks have ended; or 

b) For ordered tasks, all head of queue tasks and all older tasks have ended. 


Figure 39 — Task states 


Transition S0:S1: If a newly accepted task has the simple or ordered task attribute, it shall transition to the 
dormant task state. 

Transition S0:S2: If a newly accepted task has the head of queue or aca task attribute, it shall transition to the 
enabled task state. 
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Transition S1:S2: The task attribute of a dormant task shall affect the transition to the enabled task state as 
follows: 

a) A dormant task having the simple task attribute shall enter the enabled task state when all head of queue 
and older ordered tasks (see 8.4) have ended; or 

b) A dormant task having the ordered task attribute shall enter the enabled task state when all head of 
queue tasks and all older tasks (see 8.4) have ended. 

If the tst field in the Control mode page (see SPC-3) contains 000b, then the transition from dormant task to 
enabled task shall not occur while an ACA is in effect for any l_T nexus (see 5.9.2.3 and 5.9.2.4). If the tst field 
contains 001b, then dormant tasks from the faulted l_T nexus shall not transition to the enabled task state while an 
ACA is in effect for that l_T nexus (see 5.9.2.3). 

Transition S2:S3: The establishment of an ACA condition (see 8.4) shall cause zero or more enabled tasks to 
enter the blocked task state as described in 5.9.2.2. 

Transition S3:S2: When an ACA condition is cleared (see 8.4), tasks that entered the blocked state when the 
ACA condition was established (see 5.9.2.2) shall re-enter the enabled task state. 

Transition S2:S4: A task that has completed (see 8.4) or aborted (see 8.4 and 5.7) shall enter the ended task 
state. This is the only state transition that applies to an ACA task. 

Transitions S1:S4, S3:S4: A task abort event (see 8.4 and 5.7) shall cause the task to unconditionally enter the 
ended task state. 


8.9 Task set management examples 

8.9.1 Introduction 

Several task set management scenarios are shown in 8.9.2, 8.9.3, and 8.9.4. The examples are valid for configura¬ 
tions with one or multiple SCSI initiator ports when the tst field contains 000b (i.e., the interaction among tasks in 
a task set is independent of the l_T nexus on which a task is received). The examples are also valid for a single l_T 
nexus when the tst field contains 001 b (i.e., task set management proceeds independently for each l_T nexus and 
the events and transitions for the task set associated with one l_T nexus do not affect the task set management for 
task sets associated with other l_T nexuses). Throughout these examples, the scope of the task set box drawn in 
each snapshot depends on the setting of the tst field in the Control mode page (see SPC-3). 

The figure accompanying each example shows successive snapshots of a task set after various events (e.g., task 
creation or completion). In all cases, the constraints on task completion order established using Control mode page 
(see SPC-3) fields other that the tst field (e.g., the queue algorithm modifier field) are not in effect. 

A task set is shown as an ordered list or queue of tasks with the head of the queue towards the top of the figure. A 
new head of queue task always enters the task set at the head, displacing older head of queue tasks. Simple, 
ordered and ACA tasks always enter the task set at the end of the queue. 
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Tasks, denoted by rectangles, are numbered in ascending order from oldest to most recent. Fill, shape and line 
weight are used to distinguish task states and attributes are shown in table 33. 


Table 33 — Task attribute and state indications in examples 


Task Attribute 

Box Shape 

Line Weight 

Task State 

Box Fill 

SIMPLE 

ORDERED 

HEAD OF QUEUE 

ACA 

Rounded Corners 
Square Corners 
Square Corners 
Square Corners 

Thin 

Thin 

Thick 

Thin Dashed 

Enabled 

Dormant 

Blocked 

White 

Grey 

Black 


The conditions preventing a dormant task from entering enabled task state, except for ACA conditions, are shown 
by means of blocking boundaries. Such boundaries appear as horizontal lines with an arrow on both ends. The 
tasks causing the barrier condition are described as part of each example. A task is impeded by the barrier if it is 
between the boundary and the end of the queue. When ACA is not in effect, a task may enter the enabled task 
state after all intervening barriers have been removed. 

8.9.2 Head of queue tasks 

Figure 40 shows task set conditions when several head of queue tasks are processed. 


Head of Queue 
Task 1 


^Blocking boundary 


Simple Task 2 


Snapshot 1 


Head of Queue | 
Task 3 


Head of Queue | 
Task 1 


Blocking boundary 


^ Simple Task 2 J 
^ Simple Task 4 j 


Snapshot 2 


Head of Queue 
Task 1 


^Blocking boundary 


^ Simple Task 2 j 


Simple Task 4 


C 


Snapshot 3 


Figure 40 — Head of queue tasks and blocking boundaries (example 1) 


In snapshot 1 the task set contains one head of queue and one simple task. As shown by the blocking boundary, 
simple task 2 is in the dormant task state because of the head of queue task. Snapshot 2 shows the task set after 
head of queue task 3 and simple task 4 are created. The new head of queue task is placed at the front of the queue 
in the enabled task state, displacing task 1. Snapshot 3 shows the task set after task 3 completes. Since the condi¬ 
tions indicated by the task 1 blocking boundary are still in effect, tasks 2 and 4 remain in the dormant task state. 
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Figure 41 is the same as the previous example, except that task 1 completes instead of task 3. 
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Simple Task 4 
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Figure 41 — Head of queue tasks and blocking boundaries (example 2) 


Because the blocking boundary remains in place for a head of queue task, both simple tasks remain in the dormant 
task state in snapshot 3. The blocking boundary is not removed until all head of queue tasks complete. 
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8.9.3 Ordered tasks 

An example of ordered and simple task interaction is shown in figure 42. 
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Snapshot 3 


Figure 42 — Ordered tasks and blocking boundaries 


The state of dormant tasks 2 through 5 is determined by the requirements shown in table 34. 


Table 34 — Dormant task blocking boundary requirements 


Task 

Reason for blocking boundary 

2 

An ordered task is not allowed to enter the enabled task state 
until all head of queue tasks and all older tasks have ended. 

5 

3 

A simple task is not allowed to enter the enabled task state until 
all head of queue and all older ordered tasks have ended. 

4 


The table 34 constraints are shown by the blocking boundaries in snapshot 1. 

In snapshot 2, the completion of task 1 allows ordered task 2 to enter the enabled task state. Since the initial 
constraints on tasks 3, 4 and 5 are still in effect, these tasks are required to remain in the dormant task state. As 
shown in snapshot 3, the completion of task 2 triggers two state changes, with task 3 and task 4 transitioning to the 
enabled task state. Task 5 is required to remain in the dormant task state until task 3 and task 4 tasks complete. 
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8.9.4 ACA task 

Figure 43 shows the effects of an ACA condition on the task set. This example assumes the QErr field contains 
00b in the Control mode page (see SPC-3). Consequently, clearing an ACA condition does not cause tasks to be 
aborted. 
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Figure 43 — ACA task example 


The completion of task 2 with CHECK CONDITION status causes task 1 to enter the blocked task state shown in 
snapshot 2. In snapshot 3, ordered task 3 is aborted using the ABORT TASK task management function and ACA 
task 5 is created to perform additional handling for the exception. Once the ACA condition is cleared (snapshot 4), 
simple task 1 is allowed to reenter the enabled task state. Since there are no head of queue tasks or older ordered 
tasks, task 4 also transitions to the enabled task state. 
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Annex A 

(informative) 

Identifiers and names for objects 

A.1 Identifiers and names overview 

This annex summarizes SCSI identifiers and names. 

The following SCSI architecture model objects have identifiers and names summarized in this annex: 

a) SCSI initiator port (see 3.1.94); 

b) SCSI target port (see 3.1.99); 

c) Logical unit (see 3.1.60); 

d) SCSI initiator device (see 3.1.93); and 

e) SCSI target device (see 3.1.98). 

A.2 Identifiers and names 

This standard defines the identifiers and names for the objects listed in A.1. The size requirements placed on 
identifiers by this standard are as shown in table A.1. This standard places no requirements on the sizes of names. 
Table A.1 also lists whether this standard or SPC-3 requires SCSI transport protocols and logical units to support 
identifiers and names for an object. 


Table A.1 — Object size and support requirements 



Identifier 

Name 

Object 

Size 

Support 

Requirements 

Size 

Support 

Requirements 

Initiator device 

n/a 

n/a 

not specified 

optional 

Target device 

n/a 

n/a 

not specified a 

optional 

Initiator port 

not specified 

mandatory 

not specified 

optional 

Target port 

not specified 

mandatory 

not specified a 

optional 

Logical unit 

8 bytes (maximum) 

mandatory 

not specified a 

mandatory 


a Reported in the Device Identification VPD page (see SPC-3). 


Each SCSI transport protocol defines the size and format of identifiers and names for each object. 
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See table A.2 for a list of the size of the identifiers for each SCSI transport protocol. 


Table A.2 — Object identifier size for each SCSI transport protocol 


Object 

Identifier size 

SPI-5 

FCP-2 

SRP 

iSCSI 

SBP-3 

SAS SSP 

Initiator port 

4 bits a 

3 bytes 

16 bytes 

241 bytes b 

2 bytes 

8 bytes 

Target port 

4 bits a 

3 bytes 

16 bytes 

233 bytes b 

11 bytes 

8 bytes 

Logical unit 

6 bits 

(data group 
transfers) 

8 bytes 
(informa¬ 
tion unit 
transfers) 

8 bytes 

8 bytes 

8 bytes 

2 bytes 

8 bytes 


a SPI-5 uses a bit significant representation of the SCSI port identifier, therefore, the maximum 
number of SCSI ports is 16, a value that can be represented in 4 bits. 
b Maximum size, including the terminating null character byte. 
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See table A.3 for a list of the format of the identifiers for each SCSI transport protocol. 


Table A.3 — Object identifier format for each SCSI transport protocol 


Object 

Identifier format 

SPI-5 

FCP-2 

SRP 

iSCSI b 

SB P-3 

SAS SSP 

Initiator 

port 

bit significant 
(a maximum 
of 16 ports; 
one for each 
bit) 

Fibre Channel 
address 
identifier 

EUI-64 

II 8 byte 
extension a 

iSCSI name c 

II ",i,0x" II Initi¬ 
ator Session 
Identifier d 

binary value 

NAA IEEE 
Registered 
format 

Target 

port 

bit significant 
(a maximum 
of 16 ports; 
one for each 
bit) 

Fibre Channel 
address 
identifier 

EUI-64 

II 8 byte 
extension a 

iSCSI name c 

II ",t,0x" II Tar¬ 
get Portal 
Group Tag e 

EUI-64 II 
Discovery 

ID f 

NAA IEEE 
Registered 
format 

Logical 

unit 

binary value 
(6 bit) or 
as specified in 
this standard 
(see 4.9) 

as specified in 
this standard 
(see 4.9) 

as specified in 
this standard 
(see 4.9) 

as specified in 
this standard 
(see 4.9) 

binary value 
(2 bytes) 

as specified in 
this standard 
(see 4.9) 


Key: II means “concatenated with” 

",i,0x" means a UTF-8 string composed of the following five characters: comma, lowercase i, comma, 
zero, and lowercase x. 

",t,0x" means a UTF-8 string composed of the following five characters: comma, lowercase t, comma, 
zero, and lowercase x. 


a Required to be worldwide unique and recommend to be EUI-64 concatenated with an 8 byte extension. 

b iSCSI identifiers are concatenated strings containing no null characters except after the last string in the 
concatenation. 

c The iSCSI name is a worldwide unique UTF-8 string no more than 223 bytes long, not including null 
character termination if any. 

d The Initiator Session Identifier (ISID) is a UTF-8 encoded hexadecimal representation of a non-zero six 
byte integer. The ISID is represented in no more than 12 bytes, not including null character termination if 
any. 

e The Target Portal Group Tag (TPGT) is a UTF-8 encoded hexadecimal representation of a non-zero two 
byte integer. The TPGT is represented in no more than 4 bytes, not including null character termination if 
any. 

f See IEEE Std PI212 for more information on the Discovery ID. 
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See table A.4 for a list of the size of the names for each SCSI transport protocol. 

Table A.4 — Object name size for each SCSI transport protocol 


Object 

Name size a 

SPI-5 

FCP-2 

SRP 

iSCSI b 

SBP-3 

SAS SSP 

Initiator device 

not specified 

not specified 

not specified 

224 bytes 

not specified 

8 bytes 

Target device 

not specified 

not specified 

not specified 

224 bytes 

not specified 

8 bytes 

Initiator port 

not specified 

8 bytes 

16 bytes 

241 bytes 

8 bytes 

not specified 

Target port 

not specified 

8 bytes 

16 bytes 

233 bytes 

11 bytes 

not specified 

Logical unit 

Reported in the Device Identification VPD page (see SPC-3). 


a Any SCSI transport protocol may support the SCSI name string format (see SPC-3), resulting in names with 
the sizes shown in the iSCSI column. 
b Maximum size, including the terminating null character byte. 
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See table A.5 for a list of the format of the names for each SCSI transport protocol. 


Table A.5 — Object name format for each SCSI transport protocol 


Object 

Name format a 

SPI-5 

FCP-2 

SRP 

iSCSI b 

SBP-3 

SAS SSP 

Initiator device 

not specified 

not specified 

not specified 

SCSI 

name string 
format 

not specified 

NAA IEEE 
Registered 
format 

Target device 

not specified 

not specified 

not specified 

SCSI 

name string 
format 

not specified 

NAA IEEE 
Registered 
format 

Initiator port 

not specified 

Fibre 

Channel 

name_ 

identifier 

EUI-64 

II 8 byte 
extension d 

iSCSI name c 

II ",i,0x" II Initi¬ 
ator Session 

Identifier e 

EUI-64 

not specified 

Target port 

not specified 

Fibre 

Channel 

name_ 

identifier 

EUI-64 

II 8 byte 
extension d 

iSCSI name c 

II ",t,0x" II Tar¬ 
get Portal 
Group Tag f 

EUI-64 II 
Discovery 

ID 9 

not specified 

Logical unit 

Device Identification VPD page name (see SPC-3) 


Key: II means “concatenated with” 

",i,0x" means a UTF-8 string composed of the following five characters: comma, lowercase i, comma, 
zero, and lowercase x. 

",t,0x" means a UTF-8 string composed of the following five characters: comma, lowercase t, comma, 
zero, and lowercase x. 

a In addition to the name formats shown in this table, any SCSI transport protocol may support the SCSI name 
string format (see SPC-3). 

b iSCSI identifiers are concatenated strings containing no null characters except after the last string in the 
concatenation. 

c The iSCSI name is a worldwide unique UTF-8 string no more than 223 bytes long, not including null 
character termination if any. 

d Required to be worldwide unique and recommend to be EUI-64 concatenated with an 8 byte extension. 

e The Initiator Session Identifier (ISID) is a UTF-8 encoded hexadecimal representation of a non-zero six byte 
integer. The ISID is represented in no more than 12 bytes, not including null character termination if any. 

f The Target Portal Group Tag (TPGT) is a UTF-8 encoded hexadecimal representation of a non-zero two byte 
integer. The TPGT is represented in no more than 4 bytes, not including null character termination if any. 

9 See IEEE Std PI212 for more information on the Discovery ID. 


A.3 SCSI transport protocol acronyms and bibliography 

A.3.1 EUI-64 (Extended Unique Identifier, a 64-bit globally unique identifier): The IEEE maintains a tutorial 
describing EUI-64 at http://standards.ieee.org/regauth/oui/tutorials/EUI64.html. 

A.3.2 FCP-2: SCSI Fibre Channel Protocol -2 (see 1.3). 
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A.3.3 IEEE Std PI212: Standard for a Control and Status Register (CSR) Architecture for Microcomputer Buses. 
See http://www.ieee.org/. 

A.3.4 iSCSI: internet SCSI (see RFC 3720, http://www.ietf.org/rfc/rfc3720.txt). 

A.3.5 NAA: Name Address Authority (see SPC-3). 

A.3.6 SAS: Serial Attached SCSI (see 1.3). 

A.3.7 SAS SSP: SAS (see A.3.6) Serial SCSI Protocol. 

A.3.8 SBP-3: Serial Bus Protocol -3 (see 1.3). 

A.3.9 SPI-5: SCSI Parallel Interface -5 (see 1.3). 

A.3.10 SRP: SCSI RDMA Protocol (see 1.3). 

A.3.11 UTF-8: See ISO/I EC 10646-1:2000, Information technology - Universal Multiple-Octet Coded Character Set 
(UCS) - Part 1: Architecture and Basic Multilingual Plane. See http://www.iso.org/. 
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Annex B 

(informative) 

Terminology mapping 

The introduction of a model for SCSI devices with multiple ports resulted in changes in terminology between SAM 
and SAM-3 (see table B.1). 


Table B.1 — SAM-3 to SAM terminology mapping 


SAM-3 equivalent term 

SAM term 

initiator port identifier 

SCSI initiator port 

SCSI port 

SCSI port identifier 

SCSI port identifier 

SCSI target port 
target port identifier 

initiator identifier 

initiator 

port 

device identifier 

SCSI identifier 

target 

target identifier 
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